[libvirt] [PATCH] qemu: different declarations for the same method.

2018-03-08 Thread Julio Faracco
Recently, this warning is appearing while libvirt is being compiled:
Function 'qemuAssignDeviceDiskAlias' argument order different:
declaration 'vmdef, def' definition 'def, disk'

This commit change the default declaration for qemuAssignDeviceDiskAlias
specified at src/qemu/qemu_alias.c.

Signed-off-by: Julio Faracco 
---
 src/qemu/qemu_alias.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_alias.h b/src/qemu/qemu_alias.h
index 2246e712f..8c744138c 100644
--- a/src/qemu/qemu_alias.h
+++ b/src/qemu/qemu_alias.h
@@ -38,8 +38,8 @@ int qemuAssignDeviceControllerAlias(virDomainDefPtr domainDef,
 virQEMUCapsPtr qemuCaps,
 virDomainControllerDefPtr controller);
 
-int qemuAssignDeviceDiskAlias(virDomainDefPtr vmdef,
-  virDomainDiskDefPtr def);
+int qemuAssignDeviceDiskAlias(virDomainDefPtr def,
+  virDomainDiskDefPtr disk);
 
 int qemuAssignDeviceHostdevAlias(virDomainDefPtr def,
  char **alias,
-- 
2.14.1

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


[libvirt] [PATCH] fflush: be more paranoid about libio.h change

2018-03-08 Thread Paul Eggert
Suggested by Eli Zaretskii in:
https://lists.gnu.org/r/emacs-devel/2018-03/msg00270.html
* lib/fbufmode.c (fbufmode):
* lib/fflush.c (clear_ungetc_buffer_preserving_position)
(disable_seek_optimization, rpl_fflush):
* lib/fpending.c (__fpending):
* lib/fpurge.c (fpurge):
* lib/freadable.c (freadable):
* lib/freadahead.c (freadahead):
* lib/freading.c (freading):
* lib/freadptr.c (freadptr):
* lib/freadseek.c (freadptrinc):
* lib/fseeko.c (fseeko):
* lib/fseterr.c (fseterr):
* lib/fwritable.c (fwritable):
* lib/fwriting.c (fwriting):
Look at _IO_ftrylockfile as well as at _IO_EOF_SEEN.
---
 ChangeLog| 21 +
 lib/fbufmode.c   |  3 ++-
 lib/fflush.c |  9 ++---
 lib/fpending.c   |  3 ++-
 lib/fpurge.c |  3 ++-
 lib/freadable.c  |  3 ++-
 lib/freadahead.c |  3 ++-
 lib/freading.c   |  3 ++-
 lib/freadptr.c   |  3 ++-
 lib/freadseek.c  |  3 ++-
 lib/fseeko.c |  6 --
 lib/fseterr.c|  3 ++-
 lib/fwritable.c  |  3 ++-
 lib/fwriting.c   |  3 ++-
 14 files changed, 53 insertions(+), 16 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e858e18fb..a9cd4aed1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,24 @@
+2018-03-08  Paul Eggert  
+
+   fflush: be more paranoid about libio.h change
+   Suggested by Eli Zaretskii in:
+   https://lists.gnu.org/r/emacs-devel/2018-03/msg00270.html
+   * lib/fbufmode.c (fbufmode):
+   * lib/fflush.c (clear_ungetc_buffer_preserving_position)
+   (disable_seek_optimization, rpl_fflush):
+   * lib/fpending.c (__fpending):
+   * lib/fpurge.c (fpurge):
+   * lib/freadable.c (freadable):
+   * lib/freadahead.c (freadahead):
+   * lib/freading.c (freading):
+   * lib/freadptr.c (freadptr):
+   * lib/freadseek.c (freadptrinc):
+   * lib/fseeko.c (fseeko):
+   * lib/fseterr.c (fseterr):
+   * lib/fwritable.c (fwritable):
+   * lib/fwriting.c (fwriting):
+   Look at _IO_ftrylockfile as well as at _IO_EOF_SEEN.
+
 2018-03-07  Paul Eggert  
 
maint: write-file-hooks -> before-save-hook
diff --git a/lib/fbufmode.c b/lib/fbufmode.c
index f711fdfb7..73c64f348 100644
--- a/lib/fbufmode.c
+++ b/lib/fbufmode.c
@@ -31,7 +31,8 @@ fbufmode (FILE *fp)
   /* Most systems provide FILE as a struct and the necessary bitmask in
  , because they need it for implementing getc() and putc() as
  fast macros.  */
-#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
Linux libc5 */
+#if defined _IO_EOF_SEEN || defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1
+  /* GNU libc, BeOS, Haiku, Linux libc5 */
 # if HAVE___FLBF/* glibc >= 2.2 */
   if (__flbf (fp))
 return _IOLBF;
diff --git a/lib/fflush.c b/lib/fflush.c
index a6edfa105..a140b7ad9 100644
--- a/lib/fflush.c
+++ b/lib/fflush.c
@@ -33,7 +33,8 @@
 #undef fflush
 
 
-#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
Linux libc5 */
+#if defined _IO_EOF_SEEN || defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1
+/* GNU libc, BeOS, Haiku, Linux libc5 */
 
 /* Clear the stream's ungetc buffer, preserving the value of ftello (fp).  */
 static void
@@ -72,7 +73,8 @@ clear_ungetc_buffer (FILE *fp)
 
 #endif
 
-#if ! (defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
Linux libc5 */)
+#if ! (defined _IO_EOF_SEEN || defined _IO_ftrylockfile || __GNU_LIBRARY__ == 
1)
+/* GNU libc, BeOS, Haiku, Linux libc5 */
 
 # if (defined __sferror || defined __DragonFly__ || defined __ANDROID__) && 
defined __SNPT
 /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
@@ -148,7 +150,8 @@ rpl_fflush (FILE *stream)
   if (stream == NULL || ! freading (stream))
 return fflush (stream);
 
-#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
Linux libc5 */
+#if defined _IO_EOF_SEEN || defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1
+  /* GNU libc, BeOS, Haiku, Linux libc5 */
 
   clear_ungetc_buffer_preserving_position (stream);
 
diff --git a/lib/fpending.c b/lib/fpending.c
index 789f50e4e..7bc235ded 100644
--- a/lib/fpending.c
+++ b/lib/fpending.c
@@ -32,7 +32,8 @@ __fpending (FILE *fp)
   /* Most systems provide FILE as a struct and the necessary bitmask in
  , because they need it for implementing getc() and putc() as
  fast macros.  */
-#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
Linux libc5 */
+#if defined _IO_EOF_SEEN || defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1
+  /* GNU libc, BeOS, Haiku, Linux libc5 */
   return fp->_IO_write_ptr - fp->_IO_write_base;
 #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
   /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
diff --git a/lib/fpurge.c b/lib/fpurge.c
index 3aedcc373..554790b56 100644
--- a/lib/fpurge.c
+++ b/lib/fpurge.c
@@ -62,7 +62,8 @@ fpurge (FILE *fp)
   /* Most systems provide FILE as a struct and the necessary 

[libvirt] [PATCH 1/3] tools: Add the wwnn/wwpn to the man page for storage pool fields

2018-03-08 Thread John Ferlan
The description was missing the wwnn and wwpn names for the
--adapter-wwnn and --adapter-wwpn switches. Just add it to be
clear that the fields cannot be empty (IOW they are not boolean).

Signed-off-by: John Ferlan 
---
 tools/virsh.pod | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/virsh.pod b/tools/virsh.pod
index 8f0e8d74b..9fa483da3 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -3725,7 +3725,7 @@ just I<--build> is provided, then B is called 
with no flags.
 [I<--source-name name>] [I<--target path>] [I<--source-format format>]
 [I<--auth-type authtype> I<--auth-username username>
 [I<--secret-usage usage> | I<--secret-uuid uuid>]]
-[[I<--adapter-name name>] | [I<--adapter-wwnn> I<--adapter-wwpn>]
+[[I<--adapter-name name>] | [I<--adapter-wwnn> wwnn I<--adapter-wwpn> wwpn]
 [I<--adapter-parent parent>]]
 [I<--build>] [[I<--overwrite>] | [I<--no-overwrite>]] [I<--print-xml>]
 
@@ -3768,10 +3768,10 @@ be provided, but not both.
 [I<--adapter-name name>] defines the scsi_hostN adapter name to be used for
 the scsi_host adapter type pool.
 
-[I<--adapter-wwnn> I<--adapter-wwpn> [I<--adapter-parent parent>]] defines
-the wwnn and wwpn to be used for the fc_host adapter type pool. The parent
-optionally provides the name of the scsi_hostN node device to be used for
-the vHBA.
+[I<--adapter-wwnn wwnn> I<--adapter-wwpn wwpn> [I<--adapter-parent parent>]]
+defines the wwnn and wwpn to be used for the fc_host adapter type pool.
+The parent optionally provides the name of the scsi_hostN node device to
+be used for the vHBA.
 
 [I<--build>] [[I<--overwrite>] | [I<--no-overwrite>]] perform a
 B after creation in order to remove the need for a
-- 
2.13.6

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


[libvirt] [PATCH 0/3] Update the virsh pool define/create for vHBA/NPIV

2018-03-08 Thread John Ferlan
Looks like when adding support in commit 78be2e8b (and the 3 just
before it), I neglected to update the virsh command allow command
line usage of the fields.  This series updates virsh in order to
allow adding the fields (as ugly as they are) to make it easier
to define/create the pool with the fields.

John Ferlan (3):
  tools: Add the wwnn/wwpn to the man page for storage pool fields
  tools: Update the help description of the adapter-parent field
  tools: Add support for additional adapter parent options

 tools/virsh-pool.c | 29 ++---
 tools/virsh.pod| 17 -
 2 files changed, 38 insertions(+), 8 deletions(-)

-- 
2.13.6

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


[libvirt] [PATCH 2/3] tools: Update the help description of the adapter-parent field

2018-03-08 Thread John Ferlan
One short sentence won't do it justice, but it could help by listing
scsi_hostN and vHBA to point one in the right direction.

Signed-off-by: John Ferlan 
---
 tools/virsh-pool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/virsh-pool.c b/tools/virsh-pool.c
index 9c7e972ba..668e8087d 100644
--- a/tools/virsh-pool.c
+++ b/tools/virsh-pool.c
@@ -127,7 +127,7 @@
 }, \
 {.name = "adapter-parent", \
  .type = VSH_OT_STRING, \
- .help = N_("adapter parent to be used for underlying storage") \
+ .help = N_("adapter parent scsi_hostN to be used for underlying vHBA 
storage") \
 }
 
 virStoragePoolPtr
-- 
2.13.6

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


[libvirt] [PATCH 3/3] tools: Add support for additional adapter parent options

2018-03-08 Thread John Ferlan
Add the ability to provide the adapter parent_wwnn and parent_wwpn
or the parent_fabric_wwn on the virsh command line for the pool
define/create as commands.  Update the virsh.pod description.

Signed-off-by: John Ferlan 
---
 tools/virsh-pool.c | 27 +--
 tools/virsh.pod| 13 ++---
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/tools/virsh-pool.c b/tools/virsh-pool.c
index 668e8087d..36bf8d9fa 100644
--- a/tools/virsh-pool.c
+++ b/tools/virsh-pool.c
@@ -128,6 +128,18 @@
 {.name = "adapter-parent", \
  .type = VSH_OT_STRING, \
  .help = N_("adapter parent scsi_hostN to be used for underlying vHBA 
storage") \
+}, \
+{.name = "adapter-parent-wwnn", \
+ .type = VSH_OT_STRING, \
+ .help = N_("adapter parent scsi_hostN wwnn to be used for underlying vHBA 
storage") \
+}, \
+{.name = "adapter-parent-wwpn", \
+ .type = VSH_OT_STRING, \
+ .help = N_("adapter parent scsi_hostN wwpn to be used for underlying vHBA 
storage") \
+}, \
+{.name = "adapter-parent-fabric-wwn", \
+ .type = VSH_OT_STRING, \
+ .help = N_("adapter parent scsi_hostN fabric_wwn to be used for 
underlying vHBA storage") \
 }
 
 virStoragePoolPtr
@@ -309,7 +321,9 @@ virshBuildPoolXML(vshControl *ctl,
*srcDev = NULL, *srcName = NULL, *srcFormat = NULL,
*target = NULL, *authType = NULL, *authUsername = NULL,
*secretUsage = NULL, *adapterName = NULL, *adapterParent = NULL,
-   *adapterWwnn = NULL, *adapterWwpn = NULL, *secretUUID = NULL;
+   *adapterWwnn = NULL, *adapterWwpn = NULL, *secretUUID = NULL,
+   *adapterParentWwnn = NULL, *adapterParentWwpn = NULL,
+   *adapterParentFabricWwn = NULL;
 virBuffer buf = VIR_BUFFER_INITIALIZER;
 
 VSH_EXCLUSIVE_OPTIONS("secret-usage", "secret-uuid");
@@ -332,7 +346,10 @@ virshBuildPoolXML(vshControl *ctl,
 vshCommandOptStringReq(ctl, cmd, "adapter-name", ) < 0 ||
 vshCommandOptStringReq(ctl, cmd, "adapter-wwnn", ) < 0 ||
 vshCommandOptStringReq(ctl, cmd, "adapter-wwpn", ) < 0 ||
-vshCommandOptStringReq(ctl, cmd, "adapter-parent", ) < 0)
+vshCommandOptStringReq(ctl, cmd, "adapter-parent", ) < 0 
||
+vshCommandOptStringReq(ctl, cmd, "adapter-parent-wwnn", 
) < 0 ||
+vshCommandOptStringReq(ctl, cmd, "adapter-parent-wwpn", 
) < 0 ||
+vshCommandOptStringReq(ctl, cmd, "adapter-parent-fabric-wwn", 
) < 0)
 goto cleanup;
 
 virBufferAsprintf(, "\n", type);
@@ -353,6 +370,12 @@ virshBuildPoolXML(vshControl *ctl,
 virBufferAddLit(, "\n",
   adapterWwnn, adapterWwpn);
 } else if (adapterName) {
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 9fa483da3..20236885e 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -3768,10 +3768,17 @@ be provided, but not both.
 [I<--adapter-name name>] defines the scsi_hostN adapter name to be used for
 the scsi_host adapter type pool.
 
-[I<--adapter-wwnn wwnn> I<--adapter-wwpn wwpn> [I<--adapter-parent parent>]]
+[I<--adapter-wwnn wwnn> I<--adapter-wwpn wwpn> [I<--adapter-parent parent> |
+I<--adapter-parent-wwnn parent_wwnn> I |
+I<--adapter-parent-fabric-wwn parent_fabric_wwn>]]
 defines the wwnn and wwpn to be used for the fc_host adapter type pool.
-The parent optionally provides the name of the scsi_hostN node device to
-be used for the vHBA.
+Optionally provide the parent scsi_hostN node device to be used for the
+vHBA either by parent name, parent_wwnn and parent_wwpn, or parent_fabric_wwn.
+The parent name could change between reboots if the hardware environment
+changes, so providing the parent_wwnn and parent_wwpn ensure usage of the
+same physical HBA even if the scsi_hostN node device changes. Usage of the
+parent_fabric_wwn allows a bit more flexibility to choose an HBA on the
+same storage fabric in order to define the pool.
 
 [I<--build>] [[I<--overwrite>] | [I<--no-overwrite>]] perform a
 B after creation in order to remove the need for a
-- 
2.13.6

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


[libvirt] [PATCH] libvirtd: fix potential deadlock when reloading

2018-03-08 Thread Jim Fehlig
It is possible to deadlock libvirtd when concurrently starting a domain
and restarting the daemon. Threads involved in the deadlock are

Thread 4 (Thread 0x7fc13b53e700 (LWP 64084)):
#0  0x7fc13fba10bf in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x7fc14310213c in virCondWait (c=0x7fc110017fa8, m=0x7fc110017f80)
at util/virthread.c:154
#2  0x7fc1280244e9 in qemuMonitorSend (mon=0x7fc110017f70, 
msg=0x7fc13b53d240)
at qemu/qemu_monitor.c:1083
#3  0x7fc12803bf5a in qemuMonitorJSONCommandWithFd (mon=0x7fc110017f70,
cmd=0x7fc110017700, scm_fd=-1, reply=0x7fc13b53d318) at
qemu/qemu_monitor_json.c:305
#4  0x7fc12803c09c in qemuMonitorJSONCommand (mon=0x7fc110017f70,
cmd=0x7fc110017700,
reply=0x7fc13b53d318) at qemu/qemu_monitor_json.c:335
#5  0x7fc12803f116 in qemuMonitorJSONSetCapabilities (mon=0x7fc110017f70)
at qemu/qemu_monitor_json.c:1298
#6  0x7fc128026e14 in qemuMonitorSetCapabilities (mon=0x7fc110017f70)
at qemu/qemu_monitor.c:1697
#7  0x7fc127ffe250 in qemuProcessInitMonitor (driver=0x7fc12004e1e0,
vm=0x7fc110003d00, asyncJob=QEMU_ASYNC_JOB_START) at 
qemu/qemu_process.c:1763
#8  0x7fc127ffe564 in qemuConnectMonitor (driver=0x7fc12004e1e0,
vm=0x7fc110003d00,
asyncJob=6, logCtxt=0x7fc1100089c0) at qemu/qemu_process.c:1835
#9  0x7fc127fff386 in qemuProcessWaitForMonitor (driver=0x7fc12004e1e0,
vm=0x7fc110003d00, asyncJob=6, logCtxt=0x7fc1100089c0) at
qemu/qemu_process.c:2180
#10 0x7fc128009269 in qemuProcessLaunch (conn=0x7fc119a0,
driver=0x7fc12004e1e0,
vm=0x7fc110003d00, asyncJob=QEMU_ASYNC_JOB_START, incoming=0x0, 
snapshot=0x0,
vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=17) at 
qemu/qemu_process.c:6111
#11 0x7fc128009e85 in qemuProcessStart (conn=0x7fc119a0,
driver=0x7fc12004e1e0,
vm=0x7fc110003d00, updatedCPU=0x0, asyncJob=QEMU_ASYNC_JOB_START,
migrateFrom=0x0,
migrateFd=-1, migratePath=0x0, snapshot=0x0,
vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE,
flags=17) at qemu/qemu_process.c:6334
#12 0x7fc1280552f1 in qemuDomainCreateXML (conn=0x7fc119a0,
xml=0x7fc11ed0 

Re: [libvirt] [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

2018-03-08 Thread Laszlo Ersek
On 03/08/18 16:47, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:

>> I suggest (or agree) that the property list be composed of free-form
>> name=value pairs (at least conceptually). I understand Gerd is proposing
>> a QAPI schema for this, so maybe do { property_name : "foo",
>> property_value : "bar" }, or similar. The registry of properties (names,
>> possible values, meanings) should be kept separate (although possibly
>> still under QEMU).
>>
>> For OVMF (x86), I guess the initial set of properties should come from
>> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
>> might grow or change incompatibly over time, so this is just a raw
>> starter idea.)
> 
> I really don't want to see us using firmware implementation specific
> property names in these files. It means libvirt will require knowledge
> of what each different firmware's property names mean.
> 
> We need to have some core standardized set of property names that can
> be provided by any firmware implementation using the same terminology.
> 
> If we want to /also/ provide some extra firmeware-specific property
> names that would be ok for informative purposes, but when lbivirt is
> picking which firmware file to use, it would only ever look at the
> standardized property names/values.

This is a reasonable requirement from the libvirt side.

Unfortunately (or not), it requires someone (or a tight group of people)
to collect the features of all virtual firmwares in existence, and
extract a common set of properties that maps back to each firmware one
way or another. This is not unusual (basically this is how all standards
bodies work that intend to codify existing practice), it just needs a
bunch of work and coordination. We'll have to maintain a registry.

Personally I can't comment on anything else than OVMF and the ArmVirt
firmwares.

Thanks,
Laszlo

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

Re: [libvirt] [PATCH] Add kubevirt blog to planet virttools

2018-03-08 Thread Fabian Deutsch
On Thu, Mar 8, 2018 at 5:25 PM, Daniel P. Berrangé  wrote:
> On Thu, Mar 08, 2018 at 12:40:48PM +0100, Fabian Deutsch wrote:
>> Signed-off-by: Fabian Deutsch 
>> ---
>>  updater/virt-tools/config.ini | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/updater/virt-tools/config.ini b/updater/virt-tools/config.ini
>> index ff1bff3..4b55c6c 100644
>> --- a/updater/virt-tools/config.ini
>> +++ b/updater/virt-tools/config.ini
>> @@ -179,3 +179,6 @@ name = Marcin Juszkiewicz
>>
>>  [https://dummdida.tumblr.com/tagged/virtualization/rss]
>>  name = Fabian Deutsch
>> +
>> +[http://blog.kubevirt.io/rss/]
>> +name = KubeVirt Blog
>
> I'm open to dissenting opinions, but I'm not finding the blog posts here
> compelling content for the more general virt planet audience. Feels like
> they are really targetting/suited to people actively following kubevirt.

Alright, fair enough.

For now it's pretty much a weekly update and sometimes additional content.

I did suggest it because after all we try to make kubevirt a pretty
generic VM management platform, thus even this history might be
interesting to people.

- fabian


> 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] Add Fabian Deutsch to Planet virttools

2018-03-08 Thread Fabian Deutsch
Hey Daniel,

thanks for head's up and fixing it.
I haven't sent patches via email for a while.

I'll try to take care of this in future.

- fabian


On Thu, Mar 8, 2018 at 5:21 PM, Daniel P. Berrangé  wrote:
> On Thu, Mar 08, 2018 at 12:39:44PM +0100, Fabian Deutsch wrote:
>> … who is occasionally writing about KubeVirt
>>
>> Signed-off-by: Fabian Deutsch 
>> ---
>>  updater/virt-tools/config.ini | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/updater/virt-tools/config.ini b/updater/virt-tools/config.ini
>> index a56d3b7..ff1bff3 100644
>> --- a/updater/virt-tools/config.ini
>> +++ b/updater/virt-tools/config.ini
>> @@ -176,3 +176,6 @@ faceheight = 80
>>
>>  [https://marcin.juszkiewicz.com.pl/tag/virtualization/feed/]
>>  name = Marcin Juszkiewicz
>> +
>> +[https://dummdida.tumblr.com/tagged/virtualization/rss]
>> +name = Fabian Deutsch
>
> FYI, this patch doesn't apply with 'git am' because it has ended up sent
> as a multipart text+html email and the text bit seems mangled in some
> way - the '=' turned into '=3D'. I've fixed it up manually though since
> its a real small patch, and pushed 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 7/9] qemu_driver: add support to launch security info

2018-03-08 Thread Brijesh Singh
This patch implement the internal driver API for launch event into
qemu driver. When SEV is enabled, execute 'query-sev-launch-measurement'
to get the measurement of memory encrypted through launch sequence.

Signed-off-by: Brijesh Singh 
---
 src/qemu/qemu_driver.c   | 72 
 src/qemu/qemu_monitor.c  |  8 +
 src/qemu/qemu_monitor.h  |  3 ++
 src/qemu/qemu_monitor_json.c | 32 
 src/qemu/qemu_monitor_json.h |  2 ++
 5 files changed, 117 insertions(+)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 96454c17c03d..bcd539b6aff3 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -21254,6 +21254,77 @@ qemuDomainSetLifecycleAction(virDomainPtr dom,
 return ret;
 }
 
+static int qemuDomainGetSevMeasurement(virQEMUDriverPtr driver,
+   virDomainObjPtr vm,
+   virTypedParameterPtr params,
+   int *nparams)
+{
+int ret = -1;
+char *tmp;
+virTypedParameterPtr p;
+
+if ((*nparams) == 0) {
+*nparams = 1;
+return 0;
+}
+
+if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_QUERY) < 0)
+return -1;
+
+if (qemuDomainObjEnterMonitorAsync(driver, vm, QEMU_ASYNC_JOB_NONE) < 0)
+goto endjob;
+
+tmp = qemuMonitorGetSevMeasurement(QEMU_DOMAIN_PRIVATE(vm)->mon);
+if (tmp == NULL)
+goto endjob;
+
+if (qemuDomainObjExitMonitor(driver, vm) < 0)
+goto endjob;
+
+p = [0];
+if (virTypedParameterAssign(p, VIR_DOMAIN_LAUNCH_SECURITY_SEV_MEASUREMENT,
+VIR_TYPED_PARAM_STRING, tmp) < 0)
+goto endjob;
+
+ret = 0;
+
+ endjob:
+qemuDomainObjEndJob(driver, vm);
+return ret;
+}
+
+
+static int
+qemuDomainGetLaunchSecurityInfo(virDomainPtr domain,
+virTypedParameterPtr params,
+int *nparams,
+unsigned int flags)
+{
+virQEMUDriverPtr driver = domain->conn->privateData;
+virDomainObjPtr vm;
+int ret = -1;
+
+virCheckFlags(VIR_DOMAIN_AFFECT_LIVE |
+  VIR_DOMAIN_AFFECT_CONFIG |
+  VIR_TYPED_PARAM_STRING_OKAY, -1);
+
+if (!(vm = qemuDomObjFromDomain(domain)))
+goto cleanup;
+
+if (virDomainGetLaunchSecurityInfoEnsureACL(domain->conn, vm->def) < 0)
+goto cleanup;
+
+if (vm->def->sev) {
+if (qemuDomainGetSevMeasurement(driver, vm, params, nparams) < 0)
+goto cleanup;
+}
+
+ret = 0;
+
+ cleanup:
+virDomainObjEndAPI();
+return ret;
+}
 
 static virHypervisorDriver qemuHypervisorDriver = {
 .name = QEMU_DRIVER_NAME,
@@ -21474,6 +21545,7 @@ static virHypervisorDriver qemuHypervisorDriver = {
 .domainSetVcpu = qemuDomainSetVcpu, /* 3.1.0 */
 .domainSetBlockThreshold = qemuDomainSetBlockThreshold, /* 3.2.0 */
 .domainSetLifecycleAction = qemuDomainSetLifecycleAction, /* 3.9.0 */
+.domainGetLaunchSecurityInfo = qemuDomainGetLaunchSecurityInfo, /* 4.2.0 */
 };
 
 
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 195248c88ae1..e3dd078e4e73 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -4400,3 +4400,11 @@ qemuMonitorSetWatchdogAction(qemuMonitorPtr mon,
 
 return qemuMonitorJSONSetWatchdogAction(mon, action);
 }
+
+char *
+qemuMonitorGetSevMeasurement(qemuMonitorPtr mon)
+{
+QEMU_CHECK_MONITOR_NULL(mon);
+
+return qemuMonitorJSONGetSevMeasurement(mon);
+}
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 1b2513650c58..dd0821178c47 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -1176,4 +1176,7 @@ virJSONValuePtr 
qemuMonitorQueryNamedBlockNodes(qemuMonitorPtr mon);
 
 int qemuMonitorSetWatchdogAction(qemuMonitorPtr mon,
  const char *action);
+char *
+qemuMonitorGetSevMeasurement(qemuMonitorPtr mon);
+
 #endif /* QEMU_MONITOR_H */
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 94a1af1d3f75..d652da0c4db2 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -7955,3 +7955,35 @@ qemuMonitorJSONSetWatchdogAction(qemuMonitorPtr mon,
 virJSONValueFree(reply);
 return ret;
 }
+
+char *
+qemuMonitorJSONGetSevMeasurement(qemuMonitorPtr mon)
+{
+const char *tmp;
+char *measurement = NULL;
+virJSONValuePtr cmd;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr data;
+
+if (!(cmd = qemuMonitorJSONMakeCommand("query-sev-launch-measure", NULL)))
+ return NULL;
+
+if (qemuMonitorJSONCommand(mon, cmd, ) < 0)
+goto cleanup;
+
+if (qemuMonitorJSONCheckError(cmd, reply) < 0)
+goto cleanup;
+
+data = virJSONValueObjectGetObject(reply, "return");
+
+if (!(tmp = virJSONValueObjectGetString(data, "data")))
+goto cleanup;

[libvirt] [PATCH v2 8/9] virsh: implement new command for launch security

2018-03-08 Thread Brijesh Singh
Add new 'launch-security' command, the command can be used to get or set
the launch security information when booting encrypted VMs.

Signed-off-by: Brijesh Singh 
---
 tools/virsh-domain.c | 93 
 1 file changed, 93 insertions(+)

diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 29bc8e6db18b..556dbca8e877 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -13872,6 +13872,93 @@ cmdDomFSInfo(vshControl *ctl, const vshCmd *cmd)
 return ret >= 0;
 }
 
+/*
+ * "launch-security" command
+ */
+static const vshCmdInfo info_launch_security[] = {
+{.name = "help",
+.data = N_("Get or set launch-security information")
+},
+{.name = "desc",
+.data = N_("Get or set the current launch-security information for a 
guest"
+   " domain.\n"
+   "To get the launch-security information use following 
command: \n\n"
+   "virsh # launch-security ")
+},
+{.name = NULL}
+};
+
+static const vshCmdOptDef opts_launch_security[] = {
+VIRSH_COMMON_OPT_DOMAIN_FULL(0),
+{.name = "get",
+ .type = VSH_OT_STRING,
+ .help = N_("Show the launch-security info")
+},
+VIRSH_COMMON_OPT_DOMAIN_CONFIG,
+VIRSH_COMMON_OPT_DOMAIN_LIVE,
+VIRSH_COMMON_OPT_DOMAIN_CURRENT,
+{.name = NULL}
+};
+
+static void
+virshPrintLaunchSecurityInfo(vshControl *ctl, virTypedParameterPtr params,
+ int nparams)
+{
+size_t i;
+
+for (i = 0; i < nparams; i++) {
+if (params[i].type == VIR_TYPED_PARAM_STRING)
+vshPrintExtra(ctl, "%-15s: %s\n", params[i].field, 
params[i].value.s);
+}
+}
+
+static bool
+cmdLaunchSecurity(vshControl *ctl, const vshCmd *cmd)
+{
+virDomainPtr dom;
+int nparams = 0;
+virTypedParameterPtr params = NULL;
+bool ret = false;
+unsigned int flags = VIR_DOMAIN_AFFECT_CURRENT;
+bool current = vshCommandOptBool(cmd, "current");
+bool config = vshCommandOptBool(cmd, "config");
+bool live = vshCommandOptBool(cmd, "live");
+
+VSH_EXCLUSIVE_OPTIONS_VAR(current, live);
+VSH_EXCLUSIVE_OPTIONS_VAR(current, config);
+
+if (config)
+flags |= VIR_DOMAIN_AFFECT_CONFIG;
+if (live)
+flags |= VIR_DOMAIN_AFFECT_LIVE;
+
+if (!(dom = virshCommandOptDomain(ctl, cmd, NULL)))
+return false;
+
+/* get the number of parameters */
+if (virDomainGetLaunchSecurityInfo(dom, NULL, , flags) != 0) {
+vshError(ctl, "%s", _("Unable to get launch security info"));
+goto cleanup;
+}
+
+/* now go get all the launch-security parameters */
+params = vshCalloc(ctl, nparams, sizeof(*params));
+
+if (virDomainGetLaunchSecurityInfo(dom, params, , flags) != 0) {
+vshError(ctl, "%s", _("Unable to get launch security info"));
+goto cleanup;
+}
+
+virshPrintLaunchSecurityInfo(ctl, params, nparams);
+
+ret = true;
+ cleanup:
+virTypedParamsFree(params, nparams);
+virshDomainFree(dom);
+return ret;
+}
+
+
 const vshCmdDef domManagementCmds[] = {
 {.name = "attach-device",
  .handler = cmdAttachDevice,
@@ -14487,5 +14574,11 @@ const vshCmdDef domManagementCmds[] = {
  .info = info_domblkthreshold,
  .flags = 0
 },
+{.name = "launch-security",
+ .handler = cmdLaunchSecurity,
+ .opts = opts_launch_security,
+ .info = info_launch_security,
+ .flags = 0
+},
 {.name = NULL}
 };
-- 
2.14.3

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


[libvirt] [PATCH v2 0/9] x86: Secure Encrypted Virtualization (AMD)

2018-03-08 Thread Brijesh Singh
This patch series provides support for launching an encrypted guest using
AMD's new Secure Encrypted  Virtualization (SEV) feature.

SEV is an extension to the AMD-V architecture which supports running
multiple VMs under the control of a hypervisor. When enabled, SEV feature
allows the memory contents of a virtual machine (VM) to be transparently
encrypted with a key unique to the guest VM.

In order to launch SEV guest we need QEMU SEV patch [1].

[1] https://marc.info/?l=kvm=152051337301616=2

The patch series implements some of recommendation from Daniel [2]

[2] https://www.redhat.com/archives/libvir-list/2017-September/msg00197.html

At very high level the flow looks this:

1. mgmt tool calls virConnectGetDomainCapabilities. This returns an XML document
   that includes the following

   
...

  
  
  
  
   

  If  is provided then we indicate that hypervisor is capable of launching
  SEV guest. 
  
2. (optional) mgmt tool can provide the PDH and Cert-chain to guest owner in 
case
   if guest owner wish to establish a secure connection with SEV firmware to
   negotiate a key used for validating the measurement.

3. mgmt tool requests to start a guest calling virCreateXML(), passing 
VIR_DOMAIN_START_PAUSED.
   The xml would include

   
   /* the value is same as what is obtained via 
virConnectGetDomainCapabilities()
   /* the value is same as what is 
obtained via virConnectGetDomainCapabilities()
 ..  /* guest owners diffie-hellman key */ (optional)
 .. /* guest owners session blob */ (optional)
 .. /* guest policy */ (optional)

4. Libvirt generate the QEMU cli arg to enable the SEV feature, a typical
   args looks like this:

   # $QEMU ..
  -machine memory-encryption=sev0 \
  -object sev-guest,id=sev0,dh-cert-file=

5. Libvirt generates lifecycle VIR_DOMAIN_EVENT_SUSPENDED_PAUSED event

6. mgmt tool gets the VIR_DOMAIN_EVENT_SUSPENDED_PAUSED and calls 
virDomainGetLaunchSecretInfo()
   to retrieve the measurement of encrypted memory.

7. (optional) mgmt tool can provide the measurement value to guest owner, which 
can
   validate the measurement and gives GO/NO-GO answer. If mgmt tool gets GO then
   it resumes the guest otherwise it calls destroy() to kill the guest.

8. mgmt tool resumes the guest

TODO:
* SEV guest require to use DMA apis for the virtio devices. In order to use the 
DMA
  apis the virtio devices must have this tag

  

  It is a bit unclear to me where these changes need to go. Do we need to
  modify the libvirt to automatically add these when SEV is enabled or
  we ask mgmt tool to make sure that it creates XML with right tag to enable
  the DMA APIs for virtio devices. I am looking for some suggestions.

Using these patches we have succesfully booted and tested a guest both with and
without SEV enabled.

SEV Firmware API spec is available at:
https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf

Changes since v1:
 * rename  ->  for domain
 * add more information about policy and other fields in domaincaps.html
 * split the domain_conf support in two patches
 * add virDomainGetLaunchInfo() to retrieve the SEV measurement
 * extend virsh command to show the domain's launch security information
 * add test cases to validate newly added  element
 * fix issues reported with 'make check' and 'make syntax-check'

The complete git tree is available at:
https://github.com/codomania/libvirt/tree/v2

Brijesh Singh (8):
  qemu: provide support to query the SEV capability
  qemu: introduce SEV feature in hypervisor capabilities
  conf: introduce launch-security element in domain
  qemu: add support to launch SEV guest
  libvirt: add new public API to get launch security info
  remote: implement the remote protocol for launch security
  qemu_driver: add support to launch security info
  virsh: implement new command for launch security

Xiaogang Chen (1):
  tests: extend tests to include sev specific tag parsing

 docs/formatdomain.html.in   | 120 
 docs/formatdomaincaps.html.in   |  40 
 docs/schemas/domaincaps.rng |  20 ++
 docs/schemas/domaincommon.rng   |  39 
 include/libvirt/libvirt-domain.h|  17 +
 src/conf/domain_capabilities.c  |  20 ++
 src/conf/domain_capabilities.h  |  14 +
 src/conf/domain_conf.c  | 111 +
 src/conf/domain_conf.h  |  27 
 src/driver-hypervisor.h |   7 +++
 src/libvirt-domain.c|  50 +++
 src/libvirt_public.syms |   5 ++
 src/qemu/qemu_capabilities.c|  45 ++
 src/qemu/qemu_capabilities.h|   1 +
 src/qemu/qemu_capspriv.h|   4 ++
 src/qemu/qemu_command.c |  33 ++
 src/qemu/qemu_driver.c  |  72 ++
 src/qemu/qemu_monitor.c |  17 +
 src/qemu/qemu_monitor.h 

[libvirt] libvirt cannot boot windows-uefi-guest with virtio disk

2018-03-08 Thread Иван Иванов
I am using libvirt 3.6 version on Ubuntu 17.10 and create domain with
command:

virt-install --name dc02 --memory 1024,maxmemory=2048 --vcpus 1 --cpu host
--boot uefi,hd,network --disk /var/lib/libvirt/images/dc02.qcow2,bus=virtio
--network bridge=br.27,model=virtio --video=qxl --memballoon virtio --hvm
--controller usb3 --machine=q35 --graphics spice,listen=192.168.69.108
Domain boot failed with BSOD message "Unaccesible boot device", but when i
change virtio-drive to sata-drive, its successfuly boot

ps -ef output for virtio-drive look like:
libvirt+ 39726 1 45 19:59 ?00:00:06 qemu-system-x86_64
-enable-kvm -name guest=dc02,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-11-dc02/master-key.aes
-machine pc-q35-2.10,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu
SandyBridge,vme=on,ss=on,vmx=on,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,xsaveopt=on,pdpe1gb=on
-drive
file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on
-drive
file=/var/lib/libvirt/qemu/nvram/dc02_VARS.fd,if=pflash,format=raw,unit=1
-m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
fab3a566-46ad-4b2c-9e65-26cb685af33a -no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-11-dc02/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet
-no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1
-boot strict=on -device
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
-device i82801b11-bridge,id=pci.2,bus=pcie.0,addr=0x1e -device
pci-bridge,chassis_nr=3,id=pci.3,bus=pci.2,addr=0x0 -device
pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device
pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 -device
pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device
pcie-root-port,port=0x14,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x4 -device
pcie-root-port,port=0x15,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x5 -device
nec-usb-xhci,id=usb,bus=pci.4,addr=0x0 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.5,addr=0x0 -drive
file=/var/lib/libvirt/images/dc02.qcow2,format=qcow2,if=none,id=drive-virtio-disk0
-device
virtio-blk-pci,scsi=off,bus=pci.6,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:16:88:b3,bus=pci.1,addr=0x0,bootindex=2
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-spice
port=5900,addr=192.168.69.108,disable-ticketing,image-compression=off,seamless-migration=on
-device
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
-device intel-hda,id=sound0,bus=pci.3,addr=0x1 -device
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev
spicevmc,id=charredir0,name=usbredir -device
usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev
spicevmc,id=charredir1,name=usbredir -device
usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device
virtio-balloon-pci,id=balloon0,bus=pci.7,addr=0x0 -msg timestamp=on

But when i run this domain with qemu-system its succsessfuly boot and work.
Cmd looks like:
qemu-system-x86_64 -machine type=pc-q35-2.8 -accel kvm -cpu host \
-cdrom /var/lib/libvirt/images/virtio-win-0.1.141.iso \
--bios /usr/share/OVMF/OVMF_CODE.fd \
-m 2048 -smp 2 -drive
file=/var/lib/libvirt/images/dc02.qcow2,index=0,media=disk,if=virtio -boot
menu=on \
-spice addr=192.168.69.108,port=5910,disable-ticketing

I cannot fugire out where i went wrong
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 4/9] qemu: add support to launch SEV guest

2018-03-08 Thread Brijesh Singh
QEMU >= 2.12 provides 'sev-guest' object which is used to launch encrypted
VMs on AMD platform using SEV feature. The various inputs required to
launch SEV guest is provided through the  tag. A typical
SEV guest launch command line looks like this:

# $QEMU ...\
  -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 ...\
  -machine memory-encryption=sev0 \

Signed-off-by: Brijesh Singh 
---
 src/qemu/qemu_command.c | 33 ++
 src/qemu/qemu_process.c | 91 +
 2 files changed, 124 insertions(+)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index fa0aa5d5c3d4..39f136a389cb 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -9663,6 +9663,36 @@ qemuBuildTPMCommandLine(virCommandPtr cmd,
 return 0;
 }
 
+static void
+qemuBuildSevCommandLine(virCommandPtr cmd,
+virDomainSevDefPtr sev)
+{
+virBuffer obj = VIR_BUFFER_INITIALIZER;
+char *path = NULL;
+
+VIR_DEBUG("policy=0x%x cbitpos=%d reduced_phys_bits=%d",
+  sev->policy, sev->cbitpos, sev->reduced_phys_bits);
+
+virCommandAddArgList(cmd, "-machine", "memory-encryption=sev0", NULL);
+
+virBufferAsprintf(, "sev-guest,id=sev0,cbitpos=%d", sev->cbitpos);
+virBufferAsprintf(, ",reduced-phys-bits=%d", sev->reduced_phys_bits);
+virBufferAsprintf(, ",policy=0x%x", sev->policy);
+
+if (sev->dh_cert) {
+ignore_value(virAsprintf(, "%s/dh_cert.base64", sev->configDir));
+virBufferAsprintf(, ",dh-cert-file=%s", path);
+VIR_FREE(path);
+}
+
+if (sev->session) {
+ignore_value(virAsprintf(, "%s/session.base64", sev->configDir));
+virBufferAsprintf(, ",session-file=%s", path);
+VIR_FREE(path);
+}
+
+virCommandAddArgList(cmd, "-object", virBufferContentAndReset(), NULL);
+}
 
 static int
 qemuBuildVMCoreInfoCommandLine(virCommandPtr cmd,
@@ -10108,6 +10138,9 @@ qemuBuildCommandLine(virQEMUDriverPtr driver,
 if (qemuBuildVMCoreInfoCommandLine(cmd, def, qemuCaps) < 0)
 goto error;
 
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV) && def->sev)
+qemuBuildSevCommandLine(cmd, def->sev);
+
 if (snapshot)
 virCommandAddArgList(cmd, "-loadvm", snapshot->def->name, NULL);
 
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 57c06c7c1550..349e12b6dc12 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3457,6 +3457,16 @@ qemuProcessBuildDestroyMemoryPathsImpl(virQEMUDriverPtr 
driver,
 }
 
 
+static void
+qemuProcessDestroySevPaths(virDomainSevDefPtr sev)
+{
+if (!sev)
+return;
+
+virFileDeleteTree(sev->configDir);
+VIR_FREE(sev->configDir);
+}
+
 int
 qemuProcessBuildDestroyMemoryPaths(virQEMUDriverPtr driver,
virDomainObjPtr vm,
@@ -5741,6 +5751,83 @@ qemuProcessPrepareDomain(virQEMUDriverPtr driver,
 return ret;
 }
 
+static int
+qemuBuildSevCreateFile(const char *configDir, const char *name,
+   const char *data)
+{
+char *configFile;
+
+if (!(configFile = virFileBuildPath(configDir, name, ".base64")))
+return -1;
+
+if (virFileRewriteStr(configFile, S_IRUSR | S_IWUSR, data) < 0) {
+virReportSystemError(errno, _("failed to write data to config '%s'"),
+ configFile);
+goto error;
+}
+
+VIR_FREE(configFile);
+return 0;
+
+ error:
+VIR_FREE(configFile);
+return -1;
+}
+
+static int
+qemuProcessPrepareSevGuestInput(virQEMUDriverPtr driver,
+virDomainObjPtr vm)
+{
+qemuDomainObjPrivatePtr priv = vm->privateData;
+virDomainDefPtr def = vm->def;
+virQEMUCapsPtr qemuCaps = priv->qemuCaps;
+virDomainSevDefPtr sev = def->sev;
+char *configDir = NULL;
+char *domPath = virDomainDefGetShortName(def);
+virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
+
+if (!sev)
+return 0;
+
+VIR_DEBUG("Prepare SEV guest");
+
+if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV)) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+_("Domain %s asked for 'sev' launch but "
+  "QEMU does not support SEV feature"), vm->def->name);
+return -1;
+}
+
+if (virAsprintf(, "%s/sev/%s", cfg->configDir, domPath) < 0)
+goto error;
+
+if (virFileMakePathWithMode(configDir, S_IRWXU) < 0) {
+virReportSystemError(errno, _("cannot create config directory '%s'"),
+ configDir);
+goto error;
+}
+
+if (sev->dh_cert) {
+if (qemuBuildSevCreateFile(configDir, "dh_cert", sev->dh_cert) < 0)
+goto error1;
+}
+
+if (sev->session) {
+if (qemuBuildSevCreateFile(configDir, "session", sev->session) < 0)
+goto error1;
+}
+
+VIR_FREE(domPath);
+sev->configDir = configDir;
+return 0;
+
+ error1:

[libvirt] [PATCH v2 9/9] tests: extend tests to include sev specific tag parsing

2018-03-08 Thread Brijesh Singh
From: Xiaogang Chen 

Update qemuxml2xmltest, genericxml2xmltest and qemuxml2argvtest to include
sev specific tag, a typical SEV specific tag looks like


+  foobar
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219136
+  219136
+  1
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+  
+  
+47
+1
+1
+  
+
diff --git a/tests/genericxml2xmloutdata/sev.xml 
b/tests/genericxml2xmloutdata/sev.xml
new file mode 100644
index ..6f9a09d3a133
--- /dev/null
+++ b/tests/genericxml2xmloutdata/sev.xml
@@ -0,0 +1,22 @@
+
+  foobar
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219136
+  219136
+  1
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+  
+  
+47
+1
+1
+  
+
diff --git a/tests/genericxml2xmltest.c b/tests/genericxml2xmltest.c
index c33fce192237..0ab95c000322 100644
--- a/tests/genericxml2xmltest.c
+++ b/tests/genericxml2xmltest.c
@@ -141,6 +141,8 @@ mymain(void)
 DO_TEST_FULL("cachetune-colliding-types", false, true,
  TEST_COMPARE_DOM_XML2XML_RESULT_FAIL_PARSE);
 
+DO_TEST_DIFFERENT("sev");
+
 virObjectUnref(caps);
 virObjectUnref(xmlopt);
 
diff --git a/tests/qemuxml2argvdata/sev.args b/tests/qemuxml2argvdata/sev.args
new file mode 100644
index ..67f5505bf91d
--- /dev/null
+++ b/tests/qemuxml2argvdata/sev.args
@@ -0,0 +1,25 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-i686 \
+-name QEMUGuest1 \
+-S \
+-M pc \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-chardev 
socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\
+server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=readline \
+-no-acpi \
+-boot c \
+-usb \
+-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-ide0-0-0 \
+-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
+-machine memory-encryption=sev0 \
+-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x1
diff --git a/tests/qemuxml2argvdata/sev.xml b/tests/qemuxml2argvdata/sev.xml
new file mode 100644
index ..267ea0cf4806
--- /dev/null
+++ b/tests/qemuxml2argvdata/sev.xml
@@ -0,0 +1,35 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-i686
+
+  
+  
+  
+  
+
+
+
+
+
+
+
+  
+  
+47
+1
+1
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 688846b9b464..382fa1a5f07d 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2966,6 +2966,8 @@ mymain(void)
 QEMU_CAPS_HDA_DUPLEX);
 DO_TEST("user-aliases2", QEMU_CAPS_DEVICE_IOH3420, QEMU_CAPS_ICH9_AHCI);
 
+DO_TEST("sev", QEMU_CAPS_SEV);
+
 if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL)
 virFileDeleteTree(fakerootdir);
 
diff --git a/tests/qemuxml2xmloutdata/sev.xml b/tests/qemuxml2xmloutdata/sev.xml
new file mode 100644
index ..e603326799c1
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/sev.xml
@@ -0,0 +1,39 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-i686
+
+  
+  
+  
+  
+
+
+  
+
+
+  
+
+
+
+
+
+  
+  
+47
+1
+1
+  
+
diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
index 0eb9e6c77a77..709405683652 100644
--- a/tests/qemuxml2xmltest.c
+++ b/tests/qemuxml2xmltest.c
@@ -1344,6 +1344,8 @@ mymain(void)
 
 DO_TEST("user-aliases", NONE);
 
+DO_TEST("sev", NONE);
+
 if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL)
 virFileDeleteTree(fakerootdir);
 
-- 
2.14.3

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


[libvirt] [PATCH v2 6/9] remote: implement the remote protocol for launch security

2018-03-08 Thread Brijesh Singh
Add remote support for launch security info.

Signed-off-by: Brijesh Singh 
---
 src/remote/remote_daemon_dispatch.c | 63 +
 src/remote/remote_driver.c  | 52 +-
 src/remote/remote_protocol.x| 22 -
 src/remote_protocol-structs | 13 
 4 files changed, 148 insertions(+), 2 deletions(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index ea67cb7bc018..d3343c9ec972 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -3087,6 +3087,69 @@ remoteDispatchNodeGetMemoryStats(virNetServerPtr server 
ATTRIBUTE_UNUSED,
 return rv;
 }
 
+static int
+remoteDispatchDomainGetLaunchSecurityInfo(virNetServerPtr server 
ATTRIBUTE_UNUSED,
+  virNetServerClientPtr client 
ATTRIBUTE_UNUSED,
+  virNetMessagePtr msg 
ATTRIBUTE_UNUSED,
+  virNetMessageErrorPtr rerr,
+  
remote_domain_get_launch_security_info_args *args,
+  
remote_domain_get_launch_security_info_ret *ret)
+{
+virDomainPtr dom = NULL;
+virTypedParameterPtr params = NULL;
+int nparams = 0;
+int rv = -1;
+unsigned int flags;
+struct daemonClientPrivate *priv =
+virNetServerClientGetPrivateData(client);
+
+if (!priv->conn) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("connection not open"));
+goto cleanup;
+}
+
+flags = args->flags;
+
+if (args->nparams > REMOTE_DOMAIN_LAUNCH_SECURITY_INFO_PARAMS_MAX) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large"));
+goto cleanup;
+}
+
+if (args->nparams && VIR_ALLOC_N(params, args->nparams) < 0)
+goto cleanup;
+nparams = args->nparams;
+
+if (!(dom = get_nonnull_domain(priv->conn, args->dom)))
+goto cleanup;
+
+if (virDomainGetLaunchSecurityInfo(dom, params, , args->flags) < 0)
+goto cleanup;
+
+/* In this case, we need to send back the number of parameters
+ * supported
+ */
+if (args->nparams == 0) {
+ret->nparams = nparams;
+goto success;
+}
+
+if (virTypedParamsSerialize(params, nparams,
+(virTypedParameterRemotePtr *) 
>params.params_val,
+>params.params_len,
+flags) < 0)
+goto cleanup;
+
+ success:
+rv = 0;
+
+ cleanup:
+if (rv < 0)
+virNetMessageSaveError(rerr);
+virTypedParamsFree(params, nparams);
+virObjectUnref(dom);
+return rv;
+}
+
 static int
 remoteDispatchDomainGetPerfEvents(virNetServerPtr server ATTRIBUTE_UNUSED,
   virNetServerClientPtr client 
ATTRIBUTE_UNUSED,
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 9ea726dc45c0..695ec629c5cd 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -1951,6 +1951,55 @@ remoteDomainGetNumaParameters(virDomainPtr domain,
 return rv;
 }
 
+static int
+remoteDomainGetLaunchSecurityInfo(virDomainPtr domain,
+  virTypedParameterPtr params,
+  int *nparams,
+  unsigned int flags)
+{
+int rv = -1;
+remote_domain_get_launch_security_info_args args;
+remote_domain_get_launch_security_info_ret ret;
+struct private_data *priv = domain->conn->privateData;
+
+remoteDriverLock(priv);
+
+make_nonnull_domain(, domain);
+args.flags = flags;
+args.nparams = *nparams;
+
+memset(, 0, sizeof(ret));
+if (call(domain->conn, priv, 0, 
REMOTE_PROC_DOMAIN_GET_LAUNCH_SECURITY_INFO,
+ (xdrproc_t) xdr_remote_domain_get_launch_security_info_args, 
(char *) ,
+ (xdrproc_t) xdr_remote_domain_get_launch_security_info_ret, (char 
*) ) == -1)
+goto done;
+
+/* Handle the case when the caller does not know the number of parameters
+ * and is asking for the number of parameters supported
+ */
+if (*nparams == 0) {
+*nparams = ret.nparams;
+rv = 0;
+goto cleanup;
+}
+
+if (virTypedParamsDeserialize((virTypedParameterRemotePtr) 
ret.params.params_val,
+  ret.params.params_len,
+  
REMOTE_DOMAIN_LAUNCH_SECURITY_INFO_PARAMS_MAX,
+  ,
+  nparams) < 0)
+goto cleanup;
+
+rv = 0;
+
+ cleanup:
+xdr_free((xdrproc_t) xdr_remote_domain_get_launch_security_info_ret,
+ (char *) );
+ done:
+remoteDriverUnlock(priv);
+return rv;
+}
+
 static int
 remoteDomainGetPerfEvents(virDomainPtr domain,
   virTypedParameterPtr 

[libvirt] [PATCH v2 3/9] conf: introduce launch-security element in domain

2018-03-08 Thread Brijesh Singh
The launch-security element can be used to define the security
model to use when launching a domain. Currently we support 'sev'.

When 'sev' is used, the VM will be launched with AMD SEV feature enabled.
SEV feature supports running encrypted VM under the control of KVM.
Encrypted VMs have their pages (code and data) secured such that only the
guest itself has access to the unencrypted version. Each encrypted VM is
associated with a unique encryption key; if its data is accessed to a
different entity using a different key the encrypted guests data will be
incorrectly decrypted, leading to unintelligible data.

Signed-off-by: Brijesh Singh 
---
 docs/formatdomain.html.in | 120 ++
 docs/schemas/domaincommon.rng |  39 ++
 src/conf/domain_conf.c| 111 ++
 src/conf/domain_conf.h|  27 ++
 4 files changed, 297 insertions(+)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 6fd2189cd2f4..830d2a3c59be 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -8195,6 +8195,126 @@ qemu-kvm -net nic,model=? /dev/null
 
 Note: DEA/TDEA is synonymous with DES/TDES.
 
+Secure Encrypted Virtualization (SEV)
+
+
+   The contents of the launch-security type='sev' 
element
+   is used to provide the guest owners input used for creating an encrypted
+   VM using the AMD SEV feature.
+
+   SEV is an extension to the AMD-V architecture which supports running
+   encrypted virtual machine (VMs) under the control of KVM. Encrypted
+   VMs have their pages (code and data) secured such that only the guest
+   itself has access to the unencrypted version. Each encrypted VM is
+   associated with a unique encryption key; if its data is accessed to a
+   different entity using a different key the encrypted guests data will
+   be incorrectly decrypted, leading to unintelligible data.
+
+   For more information see various input parameters and its format see 
SEV API spec
+   https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf;> 
https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf 
+   Since 4.2.0
+   
+
+domain
+  ...
+  launch-security type='sev'
+policy 0 /policy
+cbitpos 47 /cbitpos
+reduced-phys-bits 5 /reduced-phys-bits
+session ... /session
+dh-cert ... /dh
+  /sev
+  ...
+/domain
+
+
+
+A least cbitpos and reduced-phys-bits must be
+nested within the launch-security element.
+
+
+  cbitpos
+  The cbitpos element provides the C-bit (aka encryption 
bit)
+  location in guest page table entry. The value of cbitpos is
+  hypervisor dependent and can be obtained through the sev 
element
+  from domaincapabilities.
+  
+  reduced-phys-bits
+  The reduced-phys-bits element provides the physical
+  address bit reducation. Similar to cbitpos the value of 

+  reduced-phys-bit is hypervisor dependent and can be obtained
+  through the sev element from domaincapabilities.
+  
+  policy
+  The optional policy element provides the guest policy
+  which must be maintained by the SEV firmware. This policy is enforced by
+  the firmware and restricts what configuration and operational commands
+  can be performed on this guest by the hypervisor. The guest policy
+  provided during guest launch is bound to the guest and cannot be changed
+  throughout the lifetime of the guest. The policy is also transmitted
+  during snapshot and migration flows and enforced on the destination 
platform.
+
+  The guest policy is a 4-byte structure with the fields shown in Table:
+
+  
+
+   Bit(s) 
+   Description 
+
+
+   0 
+   Debugging of the guest is disallowed when set 
+
+
+   1 
+   Sharing keys with other guests is disallowed when set 
+
+
+   2 
+   SEV-ES is required when set
+
+
+   3 
+   Sending the guest to another platform is disallowed when 
set
+
+
+   4 
+   The guest must not be transmitted to another platform that is
+   not in the domain when set. 
+
+
+   5 
+   The guest must not be transmitted to another platform that is
+   not SEV capable when set. 
+
+
+   15:6 
+   reserved 
+
+
+   16:32 
+   The guest must not be transmitted to another platform with a
+   lower firmware version. 
+
+  
+  Default value is 0x1
+
+  
+  dh-cert
+  The optional dh-cert element provides the guest owners 
public
+  Diffie-Hellman (DH) key. The key is used to negotiate a master secret
+  key between 

[libvirt] [PATCH v2 1/9] qemu: provide support to query the SEV capability

2018-03-08 Thread Brijesh Singh
QEMU version >= 2.12 provides support for launching an encrypted VMs on
AMD x86 platform using Secure Encrypted Virtualization (SEV) feature.
This patch adds support to query the SEV capability from the qemu.

Signed-off-by: Brijesh Singh 
---
 src/conf/domain_capabilities.h | 13 
 src/qemu/qemu_capabilities.c   | 43 +
 src/qemu/qemu_capabilities.h   |  1 +
 src/qemu/qemu_capspriv.h   |  4 +++
 src/qemu/qemu_monitor.c|  9 ++
 src/qemu/qemu_monitor.h|  3 ++
 src/qemu/qemu_monitor_json.c   | 73 ++
 src/qemu/qemu_monitor_json.h   |  3 ++
 8 files changed, 149 insertions(+)

diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
index fa4c1e442f57..83d04d4c8506 100644
--- a/src/conf/domain_capabilities.h
+++ b/src/conf/domain_capabilities.h
@@ -137,6 +137,19 @@ struct _virDomainCapsCPU {
 virDomainCapsCPUModelsPtr custom;
 };
 
+/*
+ * SEV capabilities
+ */
+typedef struct _virSEVCapability virSEVCapability;
+typedef virSEVCapability *virSEVCapabilityPtr;
+struct _virSEVCapability {
+char *pdh;
+char *cert_chain;
+int cbitpos;
+int reduced_phys_bits;
+};
+
+
 struct _virDomainCaps {
 virObjectLockable parent;
 
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index b5eb8cf46a52..68e3622a3963 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -459,6 +459,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "pl011",
   "machine.pseries.max-cpu-compat",
   "dump-completed",
+  "sev",
 );
 
 
@@ -525,6 +526,8 @@ struct _virQEMUCaps {
 size_t ngicCapabilities;
 virGICCapability *gicCapabilities;
 
+virSEVCapability *sevCapabilities;
+
 virQEMUCapsHostCPUData kvmCPU;
 virQEMUCapsHostCPUData tcgCPU;
 };
@@ -2811,6 +2814,21 @@ virQEMUCapsSetGICCapabilities(virQEMUCapsPtr qemuCaps,
 qemuCaps->ngicCapabilities = ncapabilities;
 }
 
+void
+virQEMUCapsSetSEVCapabilities(virQEMUCapsPtr qemuCaps,
+  virSEVCapability *capabilities)
+{
+virSEVCapability *cap = qemuCaps->sevCapabilities;
+
+if (cap) {
+VIR_FREE(cap->pdh);
+VIR_FREE(cap->cert_chain);
+}
+
+VIR_FREE(qemuCaps->sevCapabilities);
+
+qemuCaps->sevCapabilities = capabilities;
+}
 
 static int
 virQEMUCapsProbeQMPCommands(virQEMUCapsPtr qemuCaps,
@@ -3318,6 +3336,19 @@ virQEMUCapsProbeQMPGICCapabilities(virQEMUCapsPtr 
qemuCaps,
 return 0;
 }
 
+static int
+virQEMUCapsProbeQMPSEVCapabilities(virQEMUCapsPtr qemuCaps,
+   qemuMonitorPtr mon)
+{
+virSEVCapability *caps = NULL;
+
+if (qemuMonitorGetSEVCapabilities(mon, ) < 0)
+return -1;
+
+virQEMUCapsSetSEVCapabilities(qemuCaps, caps);
+
+return 0;
+}
 
 bool
 virQEMUCapsCPUFilterFeatures(const char *name,
@@ -4896,6 +4927,12 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT);
 }
 
+/* no way to query -object sev-guest */
+if (ARCH_IS_X86(qemuCaps->arch) &&
+qemuCaps->version >= 2012000) {
+virQEMUCapsSet(qemuCaps, QEMU_CAPS_SEV);
+}
+
 if (virQEMUCapsProbeQMPCommands(qemuCaps, mon) < 0)
 goto cleanup;
 
@@ -4951,6 +4988,12 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
 virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_CACHE);
 
+/* Probe for SEV capabilities */
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV)) {
+if (virQEMUCapsProbeQMPSEVCapabilities(qemuCaps, mon) < 0)
+virQEMUCapsClear(qemuCaps, QEMU_CAPS_SEV);
+}
+
 ret = 0;
  cleanup:
 return ret;
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index c2ec2be19311..02acae491ab5 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -444,6 +444,7 @@ typedef enum {
 QEMU_CAPS_DEVICE_PL011, /* -device pl011 (not user-instantiable) */
 QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT, /* -machine 
pseries,max-cpu-compat= */
 QEMU_CAPS_DUMP_COMPLETED, /* DUMP_COMPLETED event */
+QEMU_CAPS_SEV, /* -object sev-guest,... */
 
 QEMU_CAPS_LAST /* this must always be the last item */
 } virQEMUCapsFlags;
diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h
index 222f3368e3b6..1fa85cc14f07 100644
--- a/src/qemu/qemu_capspriv.h
+++ b/src/qemu/qemu_capspriv.h
@@ -86,6 +86,10 @@ virQEMUCapsSetGICCapabilities(virQEMUCapsPtr qemuCaps,
   virGICCapability *capabilities,
   size_t ncapabilities);
 
+void
+virQEMUCapsSetSEVCapabilities(virQEMUCapsPtr qemuCaps,
+  virSEVCapability *capabilities);
+
 int
 virQEMUCapsParseHelpStr(const char *qemu,
 const char *str,
diff 

[libvirt] [PATCH v2 2/9] qemu: introduce SEV feature in hypervisor capabilities

2018-03-08 Thread Brijesh Singh
Extend hypervisor capabilities to include sev feature. When available,
hypervisor supports launching an encrypted VM on AMD platform. The
sev feature tag provides additional details like platform diffie-hellman
key and certificate chain which can be used by the guest owner to
establish a cryptographic session with the SEV firmware to negotiate
keys used for attestation or to provide secret during launch.

Signed-off-by: Brijesh Singh 
---
 docs/formatdomaincaps.html.in  | 40 
 docs/schemas/domaincaps.rng| 20 
 src/conf/domain_capabilities.c | 20 
 src/conf/domain_capabilities.h |  1 +
 src/qemu/qemu_capabilities.c   |  2 ++
 5 files changed, 83 insertions(+)

diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
index 6bfcaf61caae..f38314166ac3 100644
--- a/docs/formatdomaincaps.html.in
+++ b/docs/formatdomaincaps.html.in
@@ -417,6 +417,12 @@
 value3/value
   /enum
 /gic
+sev
+  pdh /pdh
+  cert-chain /cert-chain
+  cbitpos /cbitpos
+  reduced-phys-bits /reduced-phys-bits
+/sev
   /features
 /domainCapabilities
 
@@ -441,5 +447,39 @@
   gic element.
 
 
+SEV capabilities
+
+AMD Secure Encrypted Virtualization (SEV) capabilities are exposed under
+the sev element.
+SEV is an extension to the AMD-V architecture which supports running
+virtual machines (VMs) under the control of a hypervisor. When supported,
+guest owner can create a VM whose memory contents will be transparently
+encrypted with a key unique to that VM.
+
+For more details on SEV feature see:
+  https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf;>
+SEV API spec and http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf;>
+SEV White Paper
+
+
+
+
+  pdh
+  Platform diffie-hellman key, which can be exported to remote entities
+  which wish to establish a secure transport context with the SEV platform
+  in order to transmit data securely. The key is encoded in base64
+  cert-chain
+   Platform certificate chain -- which includes platform endorsement 
key
+  (PEK), owners certificate authory (OCA) and chip endorsement key (CEK).
+  The certificate chain is encoded in base64.
+  cbitpos
+  When memory encryption is enabled, one of the physical address bit
+  (aka the C-bit) is utilized to mark if a memory page is protected. The
+  C-bit position is Hypervisor dependent.
+  reduced-phys-bits
+  When memory encryption is enabled, we loose certain bits in physical
+  address space. The number of bits we loose is hypervisor dependent.
+
+
   
 
diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng
index 39053181eb9a..53b33eb83c1f 100644
--- a/docs/schemas/domaincaps.rng
+++ b/docs/schemas/domaincaps.rng
@@ -173,6 +173,9 @@
 
   
 
+
+
+
   
 
   
@@ -184,6 +187,23 @@
 
   
 
+  
+
+  
+
+  
+  
+
+  
+  
+
+  
+  
+
+  
+
+  
+
   
 
   
diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
index f7d9be50f82d..082065fb4733 100644
--- a/src/conf/domain_capabilities.c
+++ b/src/conf/domain_capabilities.c
@@ -549,6 +549,25 @@ virDomainCapsFeatureGICFormat(virBufferPtr buf,
 FORMAT_EPILOGUE(gic);
 }
 
+static void
+virDomainCapsFeatureSEVFormat(virBufferPtr buf,
+  virSEVCapabilityPtr const sev)
+{
+if (!sev)
+return;
+
+virBufferAddLit(buf, "\n");
+virBufferAdjustIndent(buf, 2);
+virBufferAsprintf(buf, "%d\n", sev->cbitpos);
+virBufferAsprintf(buf, "%d\n",
+  sev->reduced_phys_bits);
+virBufferAsprintf(buf, "%s\n", sev->pdh);
+virBufferAsprintf(buf, "%s\n",
+  sev->cert_chain);
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+}
+
 
 char *
 virDomainCapsFormat(virDomainCapsPtr const caps)
@@ -587,6 +606,7 @@ virDomainCapsFormat(virDomainCapsPtr const caps)
 virBufferAdjustIndent(, 2);
 
 virDomainCapsFeatureGICFormat(, >gic);
+virDomainCapsFeatureSEVFormat(, caps->sev);
 
 virBufferAdjustIndent(, -2);
 virBufferAddLit(, "\n");
diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
index 83d04d4c8506..2239566105fd 100644
--- a/src/conf/domain_capabilities.h
+++ b/src/conf/domain_capabilities.h
@@ -170,6 +170,7 @@ struct _virDomainCaps {
 /* add new domain devices here */
 
 virDomainCapsFeatureGIC gic;
+virSEVCapabilityPtr sev;
 /* add new domain features here */
 };
 
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 68e3622a3963..f56e88032c06 100644
--- a/src/qemu/qemu_capabilities.c
+++ 

[libvirt] [PATCH v2 5/9] libvirt: add new public API to get launch security info

2018-03-08 Thread Brijesh Singh
The API can be used outside the libvirt to get the launch security
information. When SEV is enabled, the API can be used to get the
measurement of the launch process.

Signed-off-by: Brijesh Singh 
---
 include/libvirt/libvirt-domain.h | 17 ++
 src/driver-hypervisor.h  |  7 ++
 src/libvirt-domain.c | 50 
 src/libvirt_public.syms  |  5 
 4 files changed, 79 insertions(+)

diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index 4048acf38aaf..11c3fec92bfa 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -4756,4 +4756,21 @@ int virDomainSetLifecycleAction(virDomainPtr domain,
 unsigned int action,
 unsigned int flags);
 
+/**
+ * Launch Security API
+ */
+
+/**
+ * VIR_DOMAIN_LAUNCH_SECURITY_SEV_MEASUREMENT:
+ *
+ * Macro represents the launch measurement of the SEV guest,
+ * as VIR_TYPED_PARAM_STRING.
+ */
+#define VIR_DOMAIN_LAUNCH_SECURITY_SEV_MEASUREMENT "sev-measurement"
+
+int virDomainGetLaunchSecurityInfo(virDomainPtr domain,
+   virTypedParameterPtr params,
+   int *nparams,
+   unsigned int flags);
+
 #endif /* __VIR_LIBVIRT_DOMAIN_H__ */
diff --git a/src/driver-hypervisor.h b/src/driver-hypervisor.h
index ce0e2b252552..dc4873a8ad1c 100644
--- a/src/driver-hypervisor.h
+++ b/src/driver-hypervisor.h
@@ -1283,6 +1283,12 @@ typedef int
   unsigned int action,
   unsigned int flags);
 
+typedef int
+(*virDrvDomainGetLaunchSecurityInfo)(virDomainPtr domain,
+ virTypedParameterPtr params,
+ int *nparams,
+ unsigned int flags);
+
 
 typedef struct _virHypervisorDriver virHypervisorDriver;
 typedef virHypervisorDriver *virHypervisorDriverPtr;
@@ -1528,6 +1534,7 @@ struct _virHypervisorDriver {
 virDrvDomainSetVcpu domainSetVcpu;
 virDrvDomainSetBlockThreshold domainSetBlockThreshold;
 virDrvDomainSetLifecycleAction domainSetLifecycleAction;
+virDrvDomainGetLaunchSecurityInfo domainGetLaunchSecurityInfo;
 };
 
 
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index eaec0979ad49..21356bb92894 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -12095,3 +12095,53 @@ int virDomainSetLifecycleAction(virDomainPtr domain,
 virDispatchError(domain->conn);
 return -1;
 }
+
+/**
+ * virDomainGetLaunchSecurityInfo:
+ * @domain: a domain object
+ * @params: where to store security info
+ * @nparams: number of items in @params
+ * @flags: bitwise-OR of virDomainModificationImpact
+ *
+ * Get the launch security info. In case of the SEV guest, this will
+ * return the launch measurement.
+ *
+ * Returns -1 in case of failure, 0 in case of success.
+ */
+int virDomainGetLaunchSecurityInfo(virDomainPtr domain,
+   virTypedParameterPtr params,
+   int *nparams,
+   unsigned int flags)
+{
+virConnectPtr conn;
+
+VIR_DOMAIN_DEBUG(domain, "params=%p, nparams=%p flags=0x%x",
+ params, nparams, flags);
+
+virResetLastError();
+
+virCheckDomainReturn(domain, -1);
+virCheckNonNegativeArgGoto(*nparams, error);
+if (*nparams != 0)
+virCheckNonNullArgGoto(params, error);
+
+if (VIR_DRV_SUPPORTS_FEATURE(domain->conn->driver, domain->conn,
+ VIR_DRV_FEATURE_TYPED_PARAM_STRING))
+flags |= VIR_TYPED_PARAM_STRING_OKAY;
+
+conn = domain->conn;
+
+if (conn->driver->domainGetLaunchSecurityInfo) {
+int ret;
+ret = conn->driver->domainGetLaunchSecurityInfo(domain, params,
+nparams, flags);
+if (ret < 0)
+goto error;
+return ret;
+}
+virReportUnsupportedError();
+
+ error:
+virDispatchError(domain->conn);
+return -1;
+}
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 95df3a0dbc7b..caba2862d371 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -785,4 +785,9 @@ LIBVIRT_4.1.0 {
 virStoragePoolLookupByTargetPath;
 } LIBVIRT_3.9.0;
 
+LIBVIRT_4.2.0 {
+global:
+virDomainGetLaunchSecurityInfo;
+} LIBVIRT_4.1.0;
+
 #  define new API here using predicted next version number 
-- 
2.14.3

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


Re: [libvirt] [PATCH] apparmor: add ro rule for sasl GSSAPI plugin on /etc/gss/mech.d/

2018-03-08 Thread Christian Ehrhardt
Thanks for the reviews, pushed with Ack/Review tags.

On Thu, Mar 8, 2018 at 9:12 AM, Jamie Strandboge 
wrote:

> On Wed, 2018-03-07 at 11:16 +0100, Christian Ehrhardt wrote:
> > If a system has sasl GSSAPI plugin available qemu with sasl support
> > will
> > try to read /etc/gss/mech.d/.
> >
> > It is required to allow that to let the modules fully work and it
> > should
> > be safe to do so as it only registers/configures plugins but has no
> > secrets.
> >
> > Signed-off-by: Christian Ehrhardt 
> > ---
> >  examples/apparmor/libvirt-qemu | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/examples/apparmor/libvirt-qemu
> > b/examples/apparmor/libvirt-qemu
> > index 950b042..2c47652 100644
> > --- a/examples/apparmor/libvirt-qemu
> > +++ b/examples/apparmor/libvirt-qemu
> > @@ -192,3 +192,7 @@
> ># silence refusals to open lttng files (see LP: #1432644)
> >deny /dev/shm/lttng-ust-wait-* r,
> >deny /run/shm/lttng-ust-wait-* r,
> > +
> > +  # required for sasl GSSAPI plugin
> > +  /etc/gss/mech.d/ r,
> > +  /etc/gss/mech.d/* r,
>
> LGTM. +1
>
> Thanks!
> --
> Jamie Strandboge | http://www.canonical.com




-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Add kubevirt blog to planet virttools

2018-03-08 Thread Daniel P . Berrangé
On Thu, Mar 08, 2018 at 12:40:48PM +0100, Fabian Deutsch wrote:
> Signed-off-by: Fabian Deutsch 
> ---
>  updater/virt-tools/config.ini | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/updater/virt-tools/config.ini b/updater/virt-tools/config.ini
> index ff1bff3..4b55c6c 100644
> --- a/updater/virt-tools/config.ini
> +++ b/updater/virt-tools/config.ini
> @@ -179,3 +179,6 @@ name = Marcin Juszkiewicz
> 
>  [https://dummdida.tumblr.com/tagged/virtualization/rss]
>  name = Fabian Deutsch
> +
> +[http://blog.kubevirt.io/rss/]
> +name = KubeVirt Blog

I'm open to dissenting opinions, but I'm not finding the blog posts here
compelling content for the more general virt planet audience. Feels like
they are really targetting/suited to people actively following kubevirt.

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] Add Fabian Deutsch to Planet virttools

2018-03-08 Thread Daniel P . Berrangé
On Thu, Mar 08, 2018 at 12:39:44PM +0100, Fabian Deutsch wrote:
> … who is occasionally writing about KubeVirt
> 
> Signed-off-by: Fabian Deutsch 
> ---
>  updater/virt-tools/config.ini | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/updater/virt-tools/config.ini b/updater/virt-tools/config.ini
> index a56d3b7..ff1bff3 100644
> --- a/updater/virt-tools/config.ini
> +++ b/updater/virt-tools/config.ini
> @@ -176,3 +176,6 @@ faceheight = 80
> 
>  [https://marcin.juszkiewicz.com.pl/tag/virtualization/feed/]
>  name = Marcin Juszkiewicz
> +
> +[https://dummdida.tumblr.com/tagged/virtualization/rss]
> +name = Fabian Deutsch

FYI, this patch doesn't apply with 'git am' because it has ended up sent
as a multipart text+html email and the text bit seems mangled in some
way - the '=' turned into '=3D'. I've fixed it up manually though since
its a real small patch, and pushed 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 v1 2/7] qemu: Add support for virtio-gpu-ccw device

2018-03-08 Thread Farhan Ali
QEMU on S390 (since v2.11) can support the virtio-gpu-ccw device,
so on S390 assign CCW address for a video device.

Also introduce a new capability for the virtio-gpu-ccw
device.

Signed-off-by: Farhan Ali 
Signed-off-by: Boris Fiuczynski 
---
 docs/formatdomain.html.in  |  3 +
 src/qemu/qemu_capabilities.c   |  5 ++
 src/qemu/qemu_capabilities.h   |  1 +
 src/qemu/qemu_command.c| 18 -
 src/qemu/qemu_domain.c |  2 +-
 src/qemu/qemu_domain_address.c |  8 +++
 src/qemu/qemu_process.c|  5 +-
 .../qemucapabilitiesdata/caps_2.11.0.s390x.replies | 83 +++---
 tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   |  3 +-
 9 files changed, 114 insertions(+), 14 deletions(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 6fd2189..0908709 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -6484,6 +6484,9 @@ qemu-kvm -net nic,model=? /dev/null
   
 The optional address sub-element can be used to
 tie the video device to a particular PCI slot.
+On S390, address can be used to provide the
+CCW address for the video device (
+since 4.2.0).
   
 
   driver
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index b5eb8cf..9db4c31 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -459,6 +459,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "pl011",
   "machine.pseries.max-cpu-compat",
   "dump-completed",
+  "virtio-gpu-ccw",
 );
 
 
@@ -1694,6 +1695,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
 { "sclplmconsole", QEMU_CAPS_DEVICE_SCLPLMCONSOLE },
 { "isa-serial", QEMU_CAPS_DEVICE_ISA_SERIAL },
 { "pl011", QEMU_CAPS_DEVICE_PL011 },
+{ "virtio-gpu-ccw", QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW },
 };
 
 static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtioBalloon[] = {
@@ -1932,6 +1934,9 @@ static struct virQEMUCapsObjectTypeProps 
virQEMUCapsObjectProps[] = {
 { "spapr-pci-host-bridge", virQEMUCapsObjectPropsSpaprPCIHostBridge,
   ARRAY_CARDINALITY(virQEMUCapsObjectPropsSpaprPCIHostBridge),
   QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE },
+{ "virtio-gpu-ccw", virQEMUCapsObjectPropsVirtioGpu,
+  ARRAY_CARDINALITY(virQEMUCapsObjectPropsVirtioGpu),
+  QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW },
 };
 
 struct virQEMUCapsPropTypeObjects {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index c2ec2be..b4852e5 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -444,6 +444,7 @@ typedef enum {
 QEMU_CAPS_DEVICE_PL011, /* -device pl011 (not user-instantiable) */
 QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT, /* -machine 
pseries,max-cpu-compat= */
 QEMU_CAPS_DUMP_COMPLETED, /* DUMP_COMPLETED event */
+QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW, /* -device virtio-gpu-ccw */
 
 QEMU_CAPS_LAST /* this must always be the last item */
 } virQEMUCapsFlags;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index fa0aa5d..ba63670 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -132,7 +132,7 @@ VIR_ENUM_IMPL(qemuDeviceVideoSecondary, 
VIR_DOMAIN_VIDEO_TYPE_LAST,
   "", /* don't support vbox */
   "qxl",
   "", /* don't support parallels */
-  "virtio-gpu-pci",
+  "virtio-gpu",
   "" /* don't support gop */);
 
 VIR_ENUM_DECL(qemuSoundCodec)
@@ -4262,7 +4262,21 @@ qemuBuildDeviceVideoStr(const virDomainDef *def,
 goto error;
 }
 
-virBufferAsprintf(, "%s,id=%s", model, video->info.alias);
+if (STREQ(model, "virtio-gpu")) {
+switch (video->info.type) {
+case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI:
+virBufferAsprintf(, "%s-pci", model);
+break;
+
+case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW:
+virBufferAsprintf(, "%s-ccw", model);
+break;
+}
+} else {
+virBufferAsprintf(, "%s", model);
+}
+
+virBufferAsprintf(, ",id=%s", video->info.alias);
 
 if (video->accel && video->accel->accel3d == VIR_TRISTATE_SWITCH_ON) {
 virBufferAsprintf(, ",virgl=%s",
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index ee02ecd..b47b4d1 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5156,7 +5156,7 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
 if (dev->data.video->type == VIR_DOMAIN_VIDEO_TYPE_DEFAULT) {
 if ARCH_IS_PPC64(def->os.arch)
 dev->data.video->type = VIR_DOMAIN_VIDEO_TYPE_VGA;
-else if (qemuDomainIsVirt(def))
+else if (qemuDomainIsVirt(def) || ARCH_IS_S390(def->os.arch))
 

[libvirt] [PATCH v1 3/7] tests: Add test case for virtio-gpu-ccw

2018-03-08 Thread Farhan Ali
A test case to test the virtio-gpu-ccw device.

Signed-off-by: Farhan Ali 
Signed-off-by: Boris Fiuczynski 
---
 .../qemuxml2argvdata/video-virtio-gpu-ccw-auto.xml | 18 ++
 tests/qemuxml2argvdata/video-virtio-gpu-ccw.args   | 25 ++
 tests/qemuxml2argvdata/video-virtio-gpu-ccw.xml| 35 
 tests/qemuxml2argvtest.c   |  7 
 .../video-virtio-gpu-ccw-auto.xml  | 34 +++
 tests/qemuxml2xmloutdata/video-virtio-gpu-ccw.xml  | 38 ++
 tests/qemuxml2xmltest.c| 14 
 7 files changed, 171 insertions(+)
 create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-ccw-auto.xml
 create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-ccw.args
 create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-ccw.xml
 create mode 100644 tests/qemuxml2xmloutdata/video-virtio-gpu-ccw-auto.xml
 create mode 100644 tests/qemuxml2xmloutdata/video-virtio-gpu-ccw.xml

diff --git a/tests/qemuxml2argvdata/video-virtio-gpu-ccw-auto.xml 
b/tests/qemuxml2argvdata/video-virtio-gpu-ccw-auto.xml
new file mode 100644
index 000..2d5da38
--- /dev/null
+++ b/tests/qemuxml2argvdata/video-virtio-gpu-ccw-auto.xml
@@ -0,0 +1,18 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1803
+  219136
+  1
+  
+hvm
+  
+  
+/usr/bin/qemu-system-s390x
+
+  
+  
+
+
+
+  
+
diff --git a/tests/qemuxml2argvdata/video-virtio-gpu-ccw.args 
b/tests/qemuxml2argvdata/video-virtio-gpu-ccw.args
new file mode 100644
index 000..e5e8854
--- /dev/null
+++ b/tests/qemuxml2argvdata/video-virtio-gpu-ccw.args
@@ -0,0 +1,25 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-s390x \
+-name QEMUGuest1 \
+-S \
+-M s390-ccw-virtio \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1803 \
+-nodefaults \
+-chardev 
socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\
+server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=readline \
+-boot c \
+-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \
+-device virtio-blk-ccw,devno=fe.0.,drive=drive-virtio-disk0,\
+id=virtio-disk0 \
+-vnc 127.0.0.1:0 \
+-device virtio-gpu-ccw,id=video0,max_outputs=1,devno=fe.0.0002 \
+-device virtio-gpu-ccw,id=video1,max_outputs=1,devno=fe.0.0003 \
+-device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001
diff --git a/tests/qemuxml2argvdata/video-virtio-gpu-ccw.xml 
b/tests/qemuxml2argvdata/video-virtio-gpu-ccw.xml
new file mode 100644
index 000..b327595
--- /dev/null
+++ b/tests/qemuxml2argvdata/video-virtio-gpu-ccw.xml
@@ -0,0 +1,35 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1803
+  219136
+  219136
+  1
+  
+hvm
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-s390x
+
+  
+  
+  
+
+
+  
+
+
+
+  
+  
+
+
+  
+  
+
+
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 688846b..59e5bda 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2966,6 +2966,13 @@ mymain(void)
 QEMU_CAPS_HDA_DUPLEX);
 DO_TEST("user-aliases2", QEMU_CAPS_DEVICE_IOH3420, QEMU_CAPS_ICH9_AHCI);
 
+DO_TEST("video-virtio-gpu-ccw", QEMU_CAPS_VIRTIO_CCW,
+QEMU_CAPS_DEVICE_VIRTIO_GPU,
+QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
+QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS,
+QEMU_CAPS_VNC,
+QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW);
+
 if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL)
 virFileDeleteTree(fakerootdir);
 
diff --git a/tests/qemuxml2xmloutdata/video-virtio-gpu-ccw-auto.xml 
b/tests/qemuxml2xmloutdata/video-virtio-gpu-ccw-auto.xml
new file mode 100644
index 000..c198dad
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/video-virtio-gpu-ccw-auto.xml
@@ -0,0 +1,34 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1803
+  219136
+  219136
+  1
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-s390x
+
+  
+  
+  
+
+
+  
+
+
+  
+  
+
+
+  
+
+
+  
+
diff --git a/tests/qemuxml2xmloutdata/video-virtio-gpu-ccw.xml 
b/tests/qemuxml2xmloutdata/video-virtio-gpu-ccw.xml
new file mode 100644
index 000..d293183
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/video-virtio-gpu-ccw.xml
@@ -0,0 +1,38 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1803
+  219136
+  219136
+  1
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-s390x
+
+  
+  
+  
+
+
+  
+
+
+  
+  
+
+
+  
+  
+
+
+  
+
+
+  
+
diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
index 0eb9e6c..766f143 100644
--- 

[libvirt] [PATCH v1 5/7] qemu: Add support for virtio input ccw devices

2018-03-08 Thread Farhan Ali
QEMU on S390 (since v2.11) can support virtio input ccw devices.
So build the qemu command line for ccw devices.

Also introduce capabilities for virtio-{keyboard, mouse, tablet}-ccw
devices.

Signed-off-by: Farhan Ali 
Signed-off-by: Boris Fiuczynski 
---
 docs/formatdomain.html.in|  2 ++
 src/qemu/qemu_capabilities.c |  8 
 src/qemu/qemu_capabilities.h |  5 +
 src/qemu/qemu_command.c  | 14 +++---
 tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml |  3 +++
 5 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 0908709..08dc74b 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -6048,6 +6048,8 @@ qemu-kvm -net nic,model=? /dev/null
   sub-element address which can tie the
   device to a particular PCI
   slot, documented above.
+  On S390, address can be used to provide a CCW address for
+  an input device (since 4.2.0).
 
   For type passthrough, the mandatory sub-element 
source
   must have an evdev attribute containing the absolute path 
to the
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 9db4c31..14564e8 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -460,6 +460,11 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "machine.pseries.max-cpu-compat",
   "dump-completed",
   "virtio-gpu-ccw",
+  "virtio-keyboard-ccw",
+
+  /* 285 */
+  "virtio-mouse-ccw",
+  "virtio-tablet-ccw",
 );
 
 
@@ -1696,6 +1701,9 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
 { "isa-serial", QEMU_CAPS_DEVICE_ISA_SERIAL },
 { "pl011", QEMU_CAPS_DEVICE_PL011 },
 { "virtio-gpu-ccw", QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW },
+{ "virtio-keyboard-ccw", QEMU_CAPS_DEVICE_VIRTIO_KEYBOARD_CCW },
+{ "virtio-mouse-ccw", QEMU_CAPS_DEVICE_VIRTIO_MOUSE_CCW },
+{ "virtio-tablet-ccw", QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW },
 };
 
 static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtioBalloon[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index b4852e5..3f3c29f 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -445,6 +445,11 @@ typedef enum {
 QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT, /* -machine 
pseries,max-cpu-compat= */
 QEMU_CAPS_DUMP_COMPLETED, /* DUMP_COMPLETED event */
 QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW, /* -device virtio-gpu-ccw */
+QEMU_CAPS_DEVICE_VIRTIO_KEYBOARD_CCW, /* -device virtio-keyboard-ccw */
+
+/* 285 */
+QEMU_CAPS_DEVICE_VIRTIO_MOUSE_CCW, /* -device virtio-mouse-ccw */
+QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW, /* -device virtio-tablet-ccw */
 
 QEMU_CAPS_LAST /* this must always be the last item */
 } virQEMUCapsFlags;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index ba63670..5477e14 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3921,6 +3921,8 @@ qemuBuildVirtioInputDevStr(const virDomainDef *def,
 
 if (dev->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) {
 suffix = "-pci";
+} else if (dev->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
+suffix = "-ccw";
 } else if (dev->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO) {
 suffix = "-device";
 } else {
@@ -3932,7 +3934,9 @@ qemuBuildVirtioInputDevStr(const virDomainDef *def,
 
 switch ((virDomainInputType) dev->type) {
 case VIR_DOMAIN_INPUT_TYPE_MOUSE:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_MOUSE)) {
+if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_MOUSE) ||
+(dev->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MOUSE_CCW))) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("virtio-mouse is not supported by this QEMU 
binary"));
 goto error;
@@ -3940,7 +3944,9 @@ qemuBuildVirtioInputDevStr(const virDomainDef *def,
 virBufferAsprintf(, "virtio-mouse%s,id=%s", suffix, 
dev->info.alias);
 break;
 case VIR_DOMAIN_INPUT_TYPE_TABLET:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_TABLET)) {
+if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_TABLET) ||
+(dev->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW))) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("virtio-tablet is not supported by this QEMU 
binary"));
 goto error;
@@ -3948,7 +3954,9 @@ qemuBuildVirtioInputDevStr(const virDomainDef *def,
 virBufferAsprintf(, "virtio-tablet%s,id=%s", suffix, 
dev->info.alias);
 

[libvirt] [PATCH v1 7/7] news: Update for virtio-gpu-ccw and virtio input ccw devices

2018-03-08 Thread Farhan Ali
Document support for the virtio-gpu-ccw and
virtio-{keyboard, mouse, tablet}-ccw devices.

Signed-off-by: Farhan Ali 
Reviewed-by: Boris Fiuczynski 
---
 docs/news.xml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index a51ca97..7eb71e3 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -35,6 +35,16 @@
 
   
 
+  
+
+  qemu: Provide virtio-gpu-ccw and virtio input ccw support
+
+
+  Support the virtio-gpu-ccw device as a video device and
+  virtio-{keyboard, mouse, tablet}-ccw devices as input devices
+  on S390.
+
+  
 
 
   
-- 
2.7.4

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


[libvirt] [PATCH v1 6/7] tests: Add test case for virtio input ccw devices

2018-03-08 Thread Farhan Ali
Test for virtio-{keyboard, mouse, tablet}-ccw.

Signed-off-by: Farhan Ali 
Signed-off-by: Boris Fiuczynski 
---
 tests/qemuxml2argvdata/input-virtio-ccw.args  | 26 +++
 tests/qemuxml2argvdata/input-virtio-ccw.xml   | 29 +
 tests/qemuxml2argvtest.c  |  8 ++
 tests/qemuxml2xmloutdata/input-virtio-ccw.xml | 36 +++
 tests/qemuxml2xmltest.c   |  9 +++
 5 files changed, 108 insertions(+)
 create mode 100644 tests/qemuxml2argvdata/input-virtio-ccw.args
 create mode 100644 tests/qemuxml2argvdata/input-virtio-ccw.xml
 create mode 100644 tests/qemuxml2xmloutdata/input-virtio-ccw.xml

diff --git a/tests/qemuxml2argvdata/input-virtio-ccw.args 
b/tests/qemuxml2argvdata/input-virtio-ccw.args
new file mode 100644
index 000..6ee318c
--- /dev/null
+++ b/tests/qemuxml2argvdata/input-virtio-ccw.args
@@ -0,0 +1,26 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-s390x \
+-name QEMUGuest1 \
+-S \
+-M s390-ccw-virtio \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1803 \
+-nographic \
+-nodefaults \
+-chardev 
socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\
+server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=readline \
+-boot c \
+-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \
+-device virtio-blk-ccw,devno=fe.0.,drive=drive-virtio-disk0,\
+id=virtio-disk0 \
+-device virtio-keyboard-ccw,id=input0,devno=fe.0.0002 \
+-device virtio-mouse-ccw,id=input1,devno=fe.0.0003 \
+-device virtio-tablet-ccw,id=input2,devno=fe.0.0004 \
+-device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001
diff --git a/tests/qemuxml2argvdata/input-virtio-ccw.xml 
b/tests/qemuxml2argvdata/input-virtio-ccw.xml
new file mode 100644
index 000..a971662
--- /dev/null
+++ b/tests/qemuxml2argvdata/input-virtio-ccw.xml
@@ -0,0 +1,29 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1803
+  219136
+  219136
+  1
+  
+hvm
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-s390x
+
+  
+  
+  
+
+
+  
+
+
+
+
+
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 59e5bda..9c1d3b5 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2973,6 +2973,14 @@ mymain(void)
 QEMU_CAPS_VNC,
 QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW);
 
+DO_TEST("input-virtio-ccw", QEMU_CAPS_VIRTIO_CCW,
+QEMU_CAPS_VIRTIO_KEYBOARD,
+QEMU_CAPS_VIRTIO_MOUSE,
+QEMU_CAPS_VIRTIO_TABLET,
+QEMU_CAPS_DEVICE_VIRTIO_KEYBOARD_CCW,
+QEMU_CAPS_DEVICE_VIRTIO_MOUSE_CCW,
+QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW);
+
 if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL)
 virFileDeleteTree(fakerootdir);
 
diff --git a/tests/qemuxml2xmloutdata/input-virtio-ccw.xml 
b/tests/qemuxml2xmloutdata/input-virtio-ccw.xml
new file mode 100644
index 000..693472b
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/input-virtio-ccw.xml
@@ -0,0 +1,36 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1803
+  219136
+  219136
+  1
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-s390x
+
+  
+  
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
index 766f143..61abf66 100644
--- a/tests/qemuxml2xmltest.c
+++ b/tests/qemuxml2xmltest.c
@@ -1358,6 +1358,15 @@ mymain(void)
 
 DO_TEST("user-aliases", NONE);
 
+DO_TEST("input-virtio-ccw",
+QEMU_CAPS_VIRTIO_CCW,
+QEMU_CAPS_VIRTIO_KEYBOARD,
+QEMU_CAPS_VIRTIO_MOUSE,
+QEMU_CAPS_VIRTIO_TABLET,
+QEMU_CAPS_DEVICE_VIRTIO_KEYBOARD_CCW,
+QEMU_CAPS_DEVICE_VIRTIO_MOUSE_CCW,
+QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW);
+
 if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL)
 virFileDeleteTree(fakerootdir);
 
-- 
2.7.4

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


[libvirt] [PATCH v1 0/7] Add support for video and input devices on S390

2018-03-08 Thread Farhan Ali
Hi,

This patch series adds Libvirt support for video and input devices 
for QEMU guests on S390. QEMU v2.11.0 added support for the 
virtio-gpu-ccw device [1] and virtio-{keyboard, mouse, tablet}-ccw devices [2], 
which can be used as video and input devices respectively.

Thanks
Farhan

[1] 
https://git.qemu.org/?p=qemu.git;a=commit;h=1f8ad88935f5cb5a2968909e392dbeee1a84b931
[2] 
https://git.qemu.org/?p=qemu.git;a=commit;h=3382cf1fabbf722dce931846853dae711838e720

Farhan Ali (7):
  qemu: Fix comment for 'qemuValidateDevicePCISlotsChipsets'
  qemu: Add support for virtio-gpu-ccw device
  tests: Add test case for virtio-gpu-ccw
  qemu: Use correct bus type for input devices
  qemu: Add support for virtio input ccw devices
  tests: Add test case for virtio input ccw devices
  news: Update for virtio-gpu-ccw and virtio input ccw devices

 docs/formatdomain.html.in  |  5 ++
 docs/news.xml  | 10 +++
 src/qemu/qemu_capabilities.c   | 13 
 src/qemu/qemu_capabilities.h   |  6 ++
 src/qemu/qemu_command.c| 32 +++--
 src/qemu/qemu_domain.c |  2 +-
 src/qemu/qemu_domain_address.c | 12 +++-
 src/qemu/qemu_process.c|  5 +-
 .../qemucapabilitiesdata/caps_2.11.0.s390x.replies | 83 +++---
 tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   |  6 +-
 tests/qemuxml2argvdata/input-virtio-ccw.args   | 26 +++
 tests/qemuxml2argvdata/input-virtio-ccw.xml| 29 
 .../qemuxml2argvdata/video-virtio-gpu-ccw-auto.xml | 18 +
 tests/qemuxml2argvdata/video-virtio-gpu-ccw.args   | 25 +++
 tests/qemuxml2argvdata/video-virtio-gpu-ccw.xml| 35 +
 tests/qemuxml2argvtest.c   | 15 
 tests/qemuxml2xmloutdata/input-virtio-ccw.xml  | 36 ++
 .../video-virtio-gpu-ccw-auto.xml  | 34 +
 tests/qemuxml2xmloutdata/video-virtio-gpu-ccw.xml  | 38 ++
 tests/qemuxml2xmltest.c| 23 ++
 20 files changed, 434 insertions(+), 19 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/input-virtio-ccw.args
 create mode 100644 tests/qemuxml2argvdata/input-virtio-ccw.xml
 create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-ccw-auto.xml
 create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-ccw.args
 create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-ccw.xml
 create mode 100644 tests/qemuxml2xmloutdata/input-virtio-ccw.xml
 create mode 100644 tests/qemuxml2xmloutdata/video-virtio-gpu-ccw-auto.xml
 create mode 100644 tests/qemuxml2xmloutdata/video-virtio-gpu-ccw.xml

-- 
2.7.4

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


[libvirt] [PATCH v1 1/7] qemu: Fix comment for 'qemuValidateDevicePCISlotsChipsets'

2018-03-08 Thread Farhan Ali
There is no function 'qemuValidateDevicePCISlotsChipsets', it
should be qemuDomainValidateDevicePCISlotsChipsets.

Signed-off-by: Farhan Ali 
Reviewed-by: Boris Fiuczynski 
---
 src/qemu/qemu_domain_address.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 3fcb36a..ae49cf2 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1815,7 +1815,7 @@ qemuDomainValidateDevicePCISlotsChipsets(virDomainDefPtr 
def,
  *  - Video (slot 2)
  *
  *  - These integrated devices were already added by
- *qemuValidateDevicePCISlotsChipsets invoked right before this function
+ *qemuDomainValidateDevicePCISlotsChipsets invoked right before this 
function
  *
  * Incrementally assign slots from 3 onwards:
  *
-- 
2.7.4

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


[libvirt] [PATCH v1 4/7] qemu: Use correct bus type for input devices

2018-03-08 Thread Farhan Ali
commit 7210cef452db 'qemu: build command line for virtio input devices'
introduced an error, by checking if input bus type is
VIR_DOMAIN_DISK_BUS_VIRTIO.

Fix it by using the correct bus type for input devices.

Signed-off-by: Farhan Ali 
Reviewed-by: Boris Fiuczynski 
---
 src/qemu/qemu_domain_address.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 49a293e..d66c3d0 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -317,7 +317,7 @@ qemuDomainPrimeVirtioDeviceAddresses(virDomainDefPtr def,
 }
 
 for (i = 0; i < def->ninputs; i++) {
-if (def->inputs[i]->bus == VIR_DOMAIN_DISK_BUS_VIRTIO &&
+if (def->inputs[i]->bus == VIR_DOMAIN_INPUT_BUS_VIRTIO &&
 def->inputs[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)
 def->inputs[i]->info.type = type;
 }
-- 
2.7.4

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


Re: [libvirt] [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

2018-03-08 Thread Daniel P . Berrangé
On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
> (
> Ard, the thread starts here:
> 
> http://mid.mail-archive.com/20180307144951.d75lo5rgzi2vf27z@eukaryote
> )
> 
> On 03/07/18 15:49, Kashyap Chamarthy wrote:
> > Problem background
> > --
> > 
> > The various OVMF binary file names and paths are slightly different[+]
> > for each Linux distribution.  And each high-level management tool
> > (libguestfs, oVirt, `virt-manager` and OpenStack Nova) is inventing its
> > own approach to detect and configure the said OVMF files.  This email
> > thread is about arriving at some common understanding to make this a bit
> > more "unified" by addressing these needs in QEMU and libvirt.
> 
> I've read Dan's message <20180307151836.gk20...@redhat.com> and Gerd's
> messages <20180308075245.lgzredyhn2paa...@sirius.home.kraxel.org>,
> <20180308074507.nwho4tddsoxb3...@sirius.home.kraxel.org>.
> 
> Those seem to cover everything, I don't have anything to add wrt.
> purpose, use case, flexibility etc.
> 
> I suggest (or agree) that the property list be composed of free-form
> name=value pairs (at least conceptually). I understand Gerd is proposing
> a QAPI schema for this, so maybe do { property_name : "foo",
> property_value : "bar" }, or similar. The registry of properties (names,
> possible values, meanings) should be kept separate (although possibly
> still under QEMU).
> 
> For OVMF (x86), I guess the initial set of properties should come from
> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
> might grow or change incompatibly over time, so this is just a raw
> starter idea.)

I really don't want to see us using firmware implementation specific
property names in these files. It means libvirt will require knowledge
of what each different firmware's property names mean.

We need to have some core standardized set of property names that can
be provided by any firmware implementation using the same terminology.

If we want to /also/ provide some extra firmeware-specific property
names that would be ok for informative purposes, but when lbivirt is
picking which firmware file to use, it would only ever look at the
standardized property names/values.

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] Libvirt and Vmware support

2018-03-08 Thread Martin Kletzander

On Thu, Mar 08, 2018 at 09:48:13AM +0100, Egoitz Aurrekoetxea wrote:

Good morning,

I had the intention to integrate Libvirt with Xen, Vmware and KVM. We
are in process of migrating to KVM but needed to integrate for some time
VMware mainly. Does it support or are plans to, support Vmware
ESX/Vcenter 6.X?.



Hi,

even though I am not using that driver, it should be possible to use it for 6.X.
I know https://libvirt.org/drvesx.html only lists it under "possibly other
versions", but that shouldn't be a problem.  If you find some, let us know.


Best regards,
--


sarenet
*Egoitz Aurrekoetxea*
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
ego...@sarenet.es 
www.sarenet.es 

Antes de imprimir este correo electrónico piense si es necesario hacerlo.



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




signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/3] Do not check for pkcheck

2018-03-08 Thread Andrea Bolognani
On Wed, 2018-03-07 at 10:29 +0100, Ján Tomko wrote:
[...]
> +dnl All we need to talk to polkit is DBus, no need to check
> +dnl for anything else.

The correct name is D-Bus, here and in the commit message.

Also, the second part of the comment ("no need...") doesn't
add any useful information, so just drop it.

Though you dropped $PKCHECK_PATH here, at the end of the file
there's still

  AC_DEFUN([LIBVIRT_RESULT_POLKIT], [
msg="$PKCHECK_PATH (version 1)"
LIBVIRT_RESULT([polkit], [$with_polkit], [$msg])
  ])

Drop both setting and using $msg please.

With the above taken care of,

  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 5/4] travis: Sync packages with libvirt-jenkins-ci

2018-03-08 Thread Daniel P . Berrangé
On Wed, Feb 28, 2018 at 02:57:21PM +0100, Andrea Bolognani wrote:
> Make sure we install the same packages lcitool would install on
> the CentOS CI so that we have consistent results. The package
> list is current as of libvirt-jenkins-ci commit ad84090b6f96.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  .travis.yml | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index a1f1d8b51d..edc6adb787 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -19,6 +19,7 @@ addons:
>- autoconf
>- automake
>- autopoint
> +  - bash-completion
>- ccache
>- dnsmasq-base
>- dwarves
> @@ -32,9 +33,9 @@ addons:
>- libaudit-dev
>- libavahi-client-dev
>- libblkid-dev
> -  - libc-dev-bin
>- libc6-dev
>- libcap-ng-dev
> +  - libc-dev-bin
>- libcurl4-gnutls-dev
>- libdbus-1-dev
>- libdevmapper-dev
> @@ -50,10 +51,12 @@ addons:
>- libpciaccess-dev
>- librbd-dev
>- libreadline-dev
> +  - libsanlock-dev
>- libsasl2-dev
>- libselinux1-dev
>- libssh2-1-dev
>- libssh-dev
> +  - libtirpc-dev
>- libtool
>- libudev-dev
>- libxen-dev
> @@ -67,7 +70,7 @@ addons:
>- parted
>- patch
>- perl
> -  - pkg-config
> +  - pkgconf
>- policykit-1
>- qemu-utils
>- radvd

Reviewed-by: Daniel P. Berrangé 


(I'll assume you've pushed this through travis already on a private branch
to ensure the build still succeeds)

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 2/3] Merge WITH_POLKIT1 and WITH_POLKIT

2018-03-08 Thread Andrea Bolognani
On Wed, 2018-03-07 at 10:29 +0100, Ján Tomko wrote:
> There is just one polkit now.
> 
> Signed-off-by: Ján Tomko 
> ---
>  m4/virt-polkit.m4 | 6 --
>  src/access/Makefile.inc.am| 6 +++---
>  src/access/viraccessmanager.c | 4 ++--
>  src/util/virpolkit.c  | 6 +++---
>  tests/Makefile.am | 4 ++--
>  5 files changed, 10 insertions(+), 16 deletions(-)

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 5/4] travis: Sync packages with libvirt-jenkins-ci

2018-03-08 Thread Andrea Bolognani
On Wed, 2018-02-28 at 14:57 +0100, Andrea Bolognani wrote:
> Make sure we install the same packages lcitool would install on
> the CentOS CI so that we have consistent results. The package
> list is current as of libvirt-jenkins-ci commit ad84090b6f96.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  .travis.yml | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Ping? Although the rest of the series is not applicable anymore,
this one patch still is.

-- 
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/3] Remove Policy-Kit support

2018-03-08 Thread Andrea Bolognani
On Wed, 2018-03-07 at 10:29 +0100, Ján Tomko wrote:
> Policy-Kit has been replaced by polkit (referred to as POLKIT0
> and POLKIT1 in our Makefiles).

... referred to, respectively, as ...

[...]
>  if WITH_POLKIT
> -if WITH_POLKIT0
> -policydir = $(datadir)/PolicyKit/policy
> -policyauth = auth_admin_keep_session
> -else ! WITH_POLKIT0
>  policydir = $(datadir)/polkit-1/actions
> -policyauth = auth_admin_keep
> -endif ! WITH_POLKIT0
>  endif WITH_POLKIT
>  
> -BUILT_SOURCES += libvirtd.policy
> -CLEANFILES += libvirtd.policy

[...]
> -libvirtd.policy: remote/libvirtd.policy.in $(top_builddir)/config.status
> - $(AM_V_GEN) sed \
> - -e 's|[@]authaction[@]|$(policyauth)|g' \
> - < $< > $@-t && \
> - mv $@-t $@

[...]
> -@authaction@
> -@authaction@
> -@authaction@
> +auth_admin_keep
> +auth_admin_keep
> +auth_admin_keep

The bit about generating the .policy file dynamically is clearly
not needed anymore after you've removed support for the second
polkit version; however, that machinery can just as well be
removed in a follow-up commit, so I'd like you to do that.

The rest looks good, so

  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 0/3] qemu: Misc capabilities cleanups

2018-03-08 Thread Ján Tomko

On Tue, Mar 06, 2018 at 04:29:12PM +0100, Andrea Bolognani wrote:

Please take a deep breath, concentrate and try to visualize a
blurb right below this sentence.


 ...


Did it work?



Nah,



Andrea Bolognani (3):
 qemu: Take full advantage of conditional device property probing
 qemu: Ignore subsequent attempts to probe device properties
 qemu: Remove virQEMUCapsProcessProps()



ACK series

Jan


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v7 10/11] qemu: Validate PCI controllers (QEMU capabilities)

2018-03-08 Thread Andrea Bolognani
Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c   | 181 ++-
 tests/qemuxml2argvtest.c |  38 +-
 tests/qemuxml2xmltest.c  |  31 ++--
 3 files changed, 127 insertions(+), 123 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 1f09b65e52..d18205c525 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4270,11 +4270,8 @@ qemuDomainDeviceDefValidateControllerSCSI(const 
virDomainControllerDef *controll
 static int
 qemuDomainDeviceDefValidateControllerPCIOld(const virDomainControllerDef 
*controller,
 const virDomainDef *def,
-virQEMUCapsPtr qemuCaps)
+virQEMUCapsPtr qemuCaps 
ATTRIBUTE_UNUSED)
 {
-virDomainControllerModelPCI model = controller->model;
-const virDomainPCIControllerOpts *pciopts;
-
 /* skip pcie-root */
 if (controller->model == VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)
 return 0;
@@ -4285,119 +4282,50 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 controller->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT)
 return 0;
 
-pciopts = >opts.pciopts;
-
-/* Second pass - now the model specific checks */
-switch (model) {
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PCI_BRIDGE)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("the pci-bridge controller is not supported "
- "in this QEMU binary"));
-return -1;
-}
-
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PXB)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("the pxb controller is not supported in this "
- "QEMU binary"));
-return -1;
-}
-
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("the dmi-to-pci-bridge (i82801b11-bridge) "
- "controller is not supported in this QEMU 
binary"));
-return -1;
-}
-
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
-if ((pciopts->modelName == 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_IOH3420) &&
-!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_IOH3420)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("the pcie-root-port (ioh3420) controller "
- "is not supported in this QEMU binary"));
-return -1;
-}
-
-if ((pciopts->modelName == 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_PCIE_ROOT_PORT) &&
-!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PCIE_ROOT_PORT)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("the pcie-root-port (pcie-root-port) controller "
- "is not supported in this QEMU binary"));
-return -1;
-}
-
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_X3130_UPSTREAM)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("the pcie-switch-upstream-port (x3130-upstream) "
- "controller is not supported in this QEMU 
binary"));
-return -1;
-}
-
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_XIO3130_DOWNSTREAM)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("The pcie-switch-downstream-port "
- "(xio3130-downstream) controller is not "
- "supported in this QEMU binary"));
-return -1;
-}
-
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PXB_PCIE)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
-   _("the pxb-pcie controller is not supported "
- "in this QEMU binary"));
-return -1;
-}
-
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
-/* Skip the implicit one */
-if (pciopts->targetIndex == 0)
-return 0;
-
-if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE)) 
{
-

[libvirt] [PATCH v7 06/11] qemu: Validate PCI controller options (busNr)

2018-03-08 Thread Andrea Bolognani
This change catches an invalid use of the option in our
test suite.

https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 42 ++
 tests/qemuxml2argvdata/pcie-expander-bus.xml   |  2 +-
 tests/qemuxml2xmloutdata/pcie-expander-bus.xml |  2 +-
 3 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index ab2420ea9c..cc7236fbdb 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4306,12 +4306,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 break;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
-if (pciopts->busNr == -1) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("autogenerated pci-expander-bus options not 
set"));
-return -1;
-}
-
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PXB)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("the pxb controller is not supported in this "
@@ -4385,12 +4379,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 break;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
-if (pciopts->busNr == -1) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("autogenerated pcie-expander-bus options not 
set"));
-return -1;
-}
-
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PXB_PCIE)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("the pxb-pcie controller is not supported "
@@ -4705,6 +4693,36 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
+/* busNr */
+switch ((virDomainControllerModelPCI) cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
+if (pciopts->busNr == -1) {
+virReportControllerMissingOption(cont, model, modelName, "busNr");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
+if (pciopts->busNr != -1) {
+virReportControllerInvalidOption(cont, model, modelName, "busNr");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
+default:
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+return -1;
+}
+
 return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
 }
 
diff --git a/tests/qemuxml2argvdata/pcie-expander-bus.xml 
b/tests/qemuxml2argvdata/pcie-expander-bus.xml
index ac01c26ccf..237430a1e5 100644
--- a/tests/qemuxml2argvdata/pcie-expander-bus.xml
+++ b/tests/qemuxml2argvdata/pcie-expander-bus.xml
@@ -35,7 +35,7 @@
   
 
 
-  
+  
 1
   
   
diff --git a/tests/qemuxml2xmloutdata/pcie-expander-bus.xml 
b/tests/qemuxml2xmloutdata/pcie-expander-bus.xml
index aaac423cac..d5e741b80d 100644
--- a/tests/qemuxml2xmloutdata/pcie-expander-bus.xml
+++ b/tests/qemuxml2xmloutdata/pcie-expander-bus.xml
@@ -36,7 +36,7 @@
 
 
   
-  
+  
 1
   
   
-- 
2.14.3

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


[libvirt] [PATCH v7 09/11] qemu: Validate PCI controller options (chassis and port)

2018-03-08 Thread Andrea Bolognani
https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 50 +-
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index a8b94f6a4a..1f09b65e52 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4320,12 +4320,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 break;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
-if (pciopts->chassis == -1 || pciopts->port == -1) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("autogenerated pcie-root-port options not set"));
-return -1;
-}
-
 if ((pciopts->modelName == 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_IOH3420) &&
 !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_IOH3420)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -4355,13 +4349,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 break;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
-if (pciopts->chassis == -1 || pciopts->port == -1) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("autogenerated pcie-switch-downstream-port "
- "options not set"));
-return -1;
-}
-
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_XIO3130_DOWNSTREAM)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("The pcie-switch-downstream-port "
@@ -4791,6 +4778,43 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
+/* chassis and port */
+switch ((virDomainControllerModelPCI) cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
+if (pciopts->chassis == -1) {
+virReportControllerMissingOption(cont, model, modelName, 
"chassis");
+return -1;
+}
+if (pciopts->port == -1) {
+virReportControllerMissingOption(cont, model, modelName, "port");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
+if (pciopts->chassis != -1) {
+virReportControllerInvalidOption(cont, model, modelName, 
"chassis");
+return -1;
+}
+if (pciopts->port != -1) {
+virReportControllerInvalidOption(cont, model, modelName, "port");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
+default:
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+}
+
 return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
 }
 
-- 
2.14.3

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


[libvirt] [PATCH v7 00/11] qemu: Validate PCI controller options

2018-03-08 Thread Andrea Bolognani
Applies cleanly on top of b932ed69f6664f42e211bdde84c8ab04e1f19033.

Patches 2/11 and 4/11 are the only ones missing R-bs, everything
else hasn't been significantly altered since [v5].

Changes from [v6]:

  * don't special-case the default PHB when checking capabilities.

Changes from [v5]:

  * patch 1 has been pushed;
  * add virReportController*() functions to cut down on redundant
error reporting, as suggested by laine;
  * report index and modelName along with model in error messages.

Changes from [v4]:

  * patch 1/12 is new;
  * use virReportEnumRangeError(), as suggested by laine.

Changes from [v3]:

  * don't introduce new test cases that won't be able to provide
full test coverage anyway, as suggested by laine.

Changes from [v2]:

  * replace the old implementation bit by bit using a clever trick
suggested by pkrempa;
  * don't move QEMU capability validation;
  * add a default: label to all switch statements as recommended
by danpb.

Changes from [v1]:

  * error out instead of silently accept invalid options;
  * shave quite a lot of yaks.

[v6] https://www.redhat.com/archives/libvir-list/2018-March/msg00203.html
[v5] https://www.redhat.com/archives/libvir-list/2018-March/msg00096.html
[v4] https://www.redhat.com/archives/libvir-list/2018-February/msg01232.html
[v3] https://www.redhat.com/archives/libvir-list/2018-February/msg00996.html
[v2] https://www.redhat.com/archives/libvir-list/2018-February/msg00813.html
[v1] https://www.redhat.com/archives/libvir-list/2018-February/msg00244.html

Andrea Bolognani (11):
  qemu: Create new qemuDomainDeviceDefValidateControllerPCI()
  qemu: Validate PCI controller options (modelName)
  qemu: Validate PCI controller options (index)
  qemu: Validate PCI controller options (targetIndex)
  qemu: Validate PCI controller options (pcihole64)
  qemu: Validate PCI controller options (busNr)
  qemu: Validate PCI controller options (numaNode)
  qemu: Validate PCI controller options (chassisNr)
  qemu: Validate PCI controller options (chassis and port)
  qemu: Validate PCI controllers (QEMU capabilities)
  qemu: Remove old qemuDomainDeviceDefValidateControllerPCI()

 src/qemu/qemu_domain.c | 531 +
 tests/qemuxml2argvdata/pcie-expander-bus.xml   |   3 -
 tests/qemuxml2argvtest.c   |  38 +-
 tests/qemuxml2xmloutdata/pcie-expander-bus.xml |   4 +-
 tests/qemuxml2xmltest.c|  31 +-
 5 files changed, 432 insertions(+), 175 deletions(-)

-- 
2.14.3

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


[libvirt] [PATCH v7 05/11] qemu: Validate PCI controller options (pcihole64)

2018-03-08 Thread Andrea Bolognani
https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index d67ef53043..ab2420ea9c 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4671,6 +4671,40 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
+/* pcihole64 */
+switch ((virDomainControllerModelPCI) cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
+/* The pcihole64 option only applies to x86 guests */
+if ((pciopts->pcihole64 ||
+ pciopts->pcihole64size != 0) &&
+!ARCH_IS_X86(def->os.arch)) {
+virReportControllerInvalidOption(cont, model, modelName, 
"pcihole64");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
+if (pciopts->pcihole64 ||
+pciopts->pcihole64size != 0) {
+virReportControllerInvalidOption(cont, model, modelName, 
"pcihole64");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
+default:
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+return -1;
+}
+
 return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
 }
 
-- 
2.14.3

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


[libvirt] [PATCH v7 08/11] qemu: Validate PCI controller options (chassisNr)

2018-03-08 Thread Andrea Bolognani
https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 8264f2bb3f..a8b94f6a4a 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4290,12 +4290,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 /* Second pass - now the model specific checks */
 switch (model) {
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
-if (pciopts->chassisNr == -1) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("autogenerated pci-bridge options not set"));
-return -1;
-}
-
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PCI_BRIDGE)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("the pci-bridge controller is not supported "
@@ -4767,6 +4761,36 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
+/* chassisNr */
+switch ((virDomainControllerModelPCI) cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
+if (pciopts->chassisNr == -1) {
+virReportControllerMissingOption(cont, model, modelName, 
"chassisNr");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
+case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
+if (pciopts->chassisNr != -1) {
+virReportControllerInvalidOption(cont, model, modelName, 
"chassisNr");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
+default:
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+return -1;
+}
+
 return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
 }
 
-- 
2.14.3

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


[libvirt] [PATCH v7 07/11] qemu: Validate PCI controller options (numaNode)

2018-03-08 Thread Andrea Bolognani
This change catches an invalid use of the option in our
test suite.

https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 44 ++
 tests/qemuxml2argvdata/pcie-expander-bus.xml   |  3 --
 tests/qemuxml2xmloutdata/pcie-expander-bus.xml |  4 +--
 3 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index cc7236fbdb..8264f2bb3f 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4723,6 +4723,50 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
+/* numaNode */
+switch ((virDomainControllerModelPCI) cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
+/* numaNode can be used for these controllers, but it's not set
+ * automatically so it can be missing */
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
+/* Only PHBs support numaNode */
+if (pciopts->numaNode != -1 &&
+pciopts->modelName != 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_SPAPR_PCI_HOST_BRIDGE) {
+virReportControllerInvalidOption(cont, model, modelName, 
"numaNode");
+return -1;
+}
+
+/* However, the default PHB doesn't support numaNode */
+if (pciopts->numaNode != -1 &&
+pciopts->modelName == 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_SPAPR_PCI_HOST_BRIDGE &&
+pciopts->targetIndex == 0) {
+virReportControllerInvalidOption(cont, model, modelName, 
"numaNode");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
+if (pciopts->numaNode != -1) {
+virReportControllerInvalidOption(cont, model, modelName, 
"numaNode");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
+default:
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+return -1;
+}
+
 return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
 }
 
diff --git a/tests/qemuxml2argvdata/pcie-expander-bus.xml 
b/tests/qemuxml2argvdata/pcie-expander-bus.xml
index 237430a1e5..5c5d34d1e0 100644
--- a/tests/qemuxml2argvdata/pcie-expander-bus.xml
+++ b/tests/qemuxml2argvdata/pcie-expander-bus.xml
@@ -35,9 +35,6 @@
   
 
 
-  
-1
-  
   
 
 
diff --git a/tests/qemuxml2xmloutdata/pcie-expander-bus.xml 
b/tests/qemuxml2xmloutdata/pcie-expander-bus.xml
index d5e741b80d..b6498fd2eb 100644
--- a/tests/qemuxml2xmloutdata/pcie-expander-bus.xml
+++ b/tests/qemuxml2xmloutdata/pcie-expander-bus.xml
@@ -36,9 +36,7 @@
 
 
   
-  
-1
-  
+  
   
 
 
-- 
2.14.3

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


[libvirt] [PATCH v7 04/11] qemu: Validate PCI controller options (targetIndex)

2018-03-08 Thread Andrea Bolognani
https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
---
 src/qemu/qemu_domain.c | 46 --
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 5e028653d0..d67ef53043 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4401,12 +4401,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 break;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
-if (pciopts->targetIndex == -1) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("autogenerated pci-root options not set"));
-return -1;
-}
-
 /* Skip the implicit one */
 if (pciopts->targetIndex == 0)
 return 0;
@@ -4637,6 +4631,46 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
+/* targetIndex */
+switch ((virDomainControllerModelPCI) cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
+/* PHBs for pSeries guests must have been assigned a targetIndex */
+if (pciopts->targetIndex == -1 &&
+pciopts->modelName == 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_SPAPR_PCI_HOST_BRIDGE) {
+virReportControllerMissingOption(cont, model, modelName, 
"targetIndex");
+return -1;
+}
+
+/* targetIndex only applies to PHBs, so for any other pci-root
+ * controller it being present is an error */
+if (pciopts->targetIndex != -1 &&
+pciopts->modelName != 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_SPAPR_PCI_HOST_BRIDGE) {
+virReportControllerInvalidOption(cont, model, modelName, 
"targetIndex");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
+if (pciopts->targetIndex != -1) {
+virReportControllerInvalidOption(cont, model, modelName, 
"targetIndex");
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
+default:
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+return -1;
+}
+
 return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
 }
 
-- 
2.14.3

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


[libvirt] [PATCH v7 02/11] qemu: Validate PCI controller options (modelName)

2018-03-08 Thread Andrea Bolognani
https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
---
 src/qemu/qemu_domain.c | 226 +++--
 1 file changed, 142 insertions(+), 84 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index f1139cbac3..d8669ee9b3 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4274,7 +4274,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 {
 virDomainControllerModelPCI model = controller->model;
 const virDomainPCIControllerOpts *pciopts;
-const char *modelName = NULL;
 
 /* skip pcie-root */
 if (controller->model == VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)
@@ -4312,24 +4311,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 }
 
 pciopts = >opts.pciopts;
-if (controller->model != VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT &&
-controller->model != VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST) {
-if (pciopts->modelName == VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_NONE) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
-   _("autogenerated %s options not set"),
-   
virDomainControllerModelPCITypeToString(controller->model));
-return -1;
-}
-
-modelName = 
virDomainControllerPCIModelNameTypeToString(pciopts->modelName);
-if (!modelName) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
-   _("unknown %s modelName value %d"),
-   
virDomainControllerModelPCITypeToString(controller->model),
-   pciopts->modelName);
-return -1;
-}
-}
 
 /* Second pass - now the model specific checks */
 switch (model) {
@@ -4340,14 +4321,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 return -1;
 }
 
-if (pciopts->modelName != 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_PCI_BRIDGE) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
-   _("PCI controller model name '%s' is not valid "
- "for a pci-bridge"),
-   modelName);
-return -1;
-}
-
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PCI_BRIDGE)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("the pci-bridge controller is not supported "
@@ -4364,14 +4337,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 return -1;
 }
 
-if (pciopts->modelName != VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_PXB) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
-   _("PCI controller model name '%s' is not valid "
- "for a pci-expander-bus"),
-   modelName);
-return -1;
-}
-
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_PXB)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("the pxb controller is not supported in this "
@@ -4382,14 +4347,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 break;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
-if (pciopts->modelName != 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_I82801B11_BRIDGE) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
-   _("PCI controller model name '%s' is not valid "
- "for a dmi-to-pci-bridge"),
-   modelName);
-return -1;
-}
-
 if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("the dmi-to-pci-bridge (i82801b11-bridge) "
@@ -4406,15 +4363,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 return -1;
 }
 
-if ((pciopts->modelName != 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_IOH3420) &&
-(pciopts->modelName != 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_PCIE_ROOT_PORT)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
-   _("PCI controller model name '%s' is not valid "
- "for a pcie-root-port"),
-   modelName);
-return -1;
-}
-
 if ((pciopts->modelName == 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_IOH3420) &&
 !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_IOH3420)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -4434,14 +4382,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 break;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
-if 

[libvirt] [PATCH v7 01/11] qemu: Create new qemuDomainDeviceDefValidateControllerPCI()

2018-03-08 Thread Andrea Bolognani
The existing function is renamed and called from the new one, so
that even while we're in the process of implementing new checks
all the existing ones will be performed.

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index ee02ecd0cd..f1139cbac3 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4268,9 +4268,9 @@ qemuDomainDeviceDefValidateControllerSCSI(const 
virDomainControllerDef *controll
 
 
 static int
-qemuDomainDeviceDefValidateControllerPCI(const virDomainControllerDef 
*controller,
- const virDomainDef *def,
- virQEMUCapsPtr qemuCaps)
+qemuDomainDeviceDefValidateControllerPCIOld(const virDomainControllerDef 
*controller,
+const virDomainDef *def,
+virQEMUCapsPtr qemuCaps)
 {
 virDomainControllerModelPCI model = controller->model;
 const virDomainPCIControllerOpts *pciopts;
@@ -4547,6 +4547,29 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *controlle
 }
 
 
+static int
+qemuDomainDeviceDefValidateControllerPCI(const virDomainControllerDef *cont,
+ const virDomainDef *def,
+ virQEMUCapsPtr qemuCaps)
+
+{
+const virDomainPCIControllerOpts *pciopts = >opts.pciopts;
+const char *model = virDomainControllerModelPCITypeToString(cont->model);
+const char *modelName = 
virDomainControllerPCIModelNameTypeToString(pciopts->modelName);
+
+if (!model) {
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+return -1;
+}
+if (!modelName) {
+virReportEnumRangeError(virDomainControllerPCIModelName, 
pciopts->modelName);
+return -1;
+}
+
+return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
+}
+
+
 static int
 qemuDomainDeviceDefValidateControllerSATA(const virDomainControllerDef 
*controller,
   const virDomainDef *def,
-- 
2.14.3

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


[libvirt] [PATCH v7 03/11] qemu: Validate PCI controller options (index)

2018-03-08 Thread Andrea Bolognani
https://bugzilla.redhat.com/show_bug.cgi?id=1483816

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 68 +++---
 1 file changed, 43 insertions(+), 25 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index d8669ee9b3..5e028653d0 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4285,31 +4285,6 @@ qemuDomainDeviceDefValidateControllerPCIOld(const 
virDomainControllerDef *contro
 controller->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT)
 return 0;
 
-/* First pass - just check the controller index for the model's
- * that we care to check... */
-switch (model) {
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
-case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
-if (controller->idx == 0) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
-   _("index for pci controllers of model '%s' must be 
> 0"),
-   virDomainControllerModelPCITypeToString(model));
-return -1;
-}
-break;
-
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
-case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
-break;
-}
-
 pciopts = >opts.pciopts;
 
 /* Second pass - now the model specific checks */
@@ -4619,6 +4594,49 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
+/* index */
+switch ((virDomainControllerModelPCI) cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS:
+if (cont->idx == 0) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   _("Index for '%s' controllers must be > 0"),
+   model);
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
+/* pSeries guests can have multiple PHBs, so it's expected that
+ * the index will not be zero for some of them */
+if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT &&
+pciopts->modelName == 
VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_SPAPR_PCI_HOST_BRIDGE) {
+break;
+}
+
+/* For all other pci-root and pcie-root controllers, though,
+ * the index must be zero*/
+if (cont->idx != 0) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   _("Index for '%s' controllers must be 0"),
+   model);
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_DEFAULT:
+case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
+default:
+virReportEnumRangeError(virDomainControllerModelPCI, cont->model);
+return -1;
+}
+
 return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
 }
 
-- 
2.14.3

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


[libvirt] [PATCH v7 11/11] qemu: Remove old qemuDomainDeviceDefValidateControllerPCI()

2018-03-08 Thread Andrea Bolognani
We've implemented all existing checks, and more, in the new
function, so we can finally drop the old one.

Signed-off-by: Andrea Bolognani 
Reviewed-by: Laine Stump 
---
 src/qemu/qemu_domain.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index d18205c525..c1359c0c83 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4267,25 +4267,6 @@ qemuDomainDeviceDefValidateControllerSCSI(const 
virDomainControllerDef *controll
 }
 
 
-static int
-qemuDomainDeviceDefValidateControllerPCIOld(const virDomainControllerDef 
*controller,
-const virDomainDef *def,
-virQEMUCapsPtr qemuCaps 
ATTRIBUTE_UNUSED)
-{
-/* skip pcie-root */
-if (controller->model == VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)
-return 0;
-
-/* Skip pci-root, except for pSeries guests (which actually
- * support more than one PCI Host Bridge per guest) */
-if (!qemuDomainIsPSeries(def) &&
-controller->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT)
-return 0;
-
-return 0;
-}
-
-
 /**
  * virDomainControllerPCIModelNameToQEMUCaps:
  * @modelName: model name
@@ -4770,7 +4751,7 @@ qemuDomainDeviceDefValidateControllerPCI(const 
virDomainControllerDef *cont,
 return -1;
 }
 
-return qemuDomainDeviceDefValidateControllerPCIOld(cont, def, qemuCaps);
+return 0;
 }
 
 
-- 
2.14.3

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


Re: [libvirt] [PATCH 0/6] Fix overly complex parsing of storage encryption/authentication

2018-03-08 Thread John Ferlan


On 03/06/2018 09:27 AM, Peter Krempa wrote:
> Peter Krempa (6):
>   util: storage: Simplify error handling in virStorageAuthDefParseXML
>   util: storage: Sanitize parsing of disk auth XMLs
>   conf: Replace virDomainDiskSourceAuthParse by an XPath query
>   util: storageencryption: Refactor cleanup section in
> virStorageEncryptionParseXML
>   util: storage: Sanitize parsing of disk encryption XMLs
>   conf: Replace virDomainDiskSourceEncryptionParse by an XPath query
> 
>  src/conf/domain_conf.c  | 69 
> +
>  src/conf/storage_conf.c |  5 ++-
>  src/util/virstorageencryption.c | 67 +--
>  src/util/virstorageencryption.h |  4 +--
>  src/util/virstoragefile.c   | 53 ++-
>  src/util/virstoragefile.h   |  3 +-
>  6 files changed, 59 insertions(+), 142 deletions(-)
> 

Reviewed-by: John Ferlan 

(series)

John

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


[libvirt] [PATCH 17/20] remote: Add the information which program has to be used to daemonClientEventCallback

2018-03-08 Thread Marc Hartmayer
As a result, you can later determine at the callback which program has
to be used. This makes it easier to refactor the code in the future
and is less prone to error.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/remote/remote_daemon_dispatch.c | 108 
 1 file changed, 59 insertions(+), 49 deletions(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index ff26574c9f6b..9580e854efbe 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -78,6 +78,7 @@ VIR_LOG_INIT("daemon.remote");
 
 struct daemonClientEventCallback {
 virNetServerClientPtr client;
+virNetServerProgramPtr program;
 int eventID;
 int callbackID;
 bool legacy;
@@ -127,6 +128,7 @@ remoteEventCallbackFree(void *opaque)
 daemonClientEventCallbackPtr callback = opaque;
 if (!callback)
 return;
+virObjectUnref(callback->program);
 virObjectUnref(callback->client);
 VIR_FREE(callback);
 }
@@ -318,7 +320,7 @@ remoteRelayDomainEventLifecycle(virConnectPtr conn,
 data.detail = detail;
 
 if (callback->legacy) {
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   REMOTE_PROC_DOMAIN_EVENT_LIFECYCLE,
   
(xdrproc_t)xdr_remote_domain_event_lifecycle_msg,
   );
@@ -326,7 +328,7 @@ remoteRelayDomainEventLifecycle(virConnectPtr conn,
 remote_domain_event_callback_lifecycle_msg msg = { 
callback->callbackID,
data };
 
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   
REMOTE_PROC_DOMAIN_EVENT_CALLBACK_LIFECYCLE,
   
(xdrproc_t)xdr_remote_domain_event_callback_lifecycle_msg,
   );
@@ -355,14 +357,14 @@ remoteRelayDomainEventReboot(virConnectPtr conn,
 make_nonnull_domain(, dom);
 
 if (callback->legacy) {
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   REMOTE_PROC_DOMAIN_EVENT_REBOOT,
   
(xdrproc_t)xdr_remote_domain_event_reboot_msg, );
 } else {
 remote_domain_event_callback_reboot_msg msg = { callback->callbackID,
 data };
 
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   REMOTE_PROC_DOMAIN_EVENT_CALLBACK_REBOOT,
   
(xdrproc_t)xdr_remote_domain_event_callback_reboot_msg, );
 }
@@ -394,14 +396,14 @@ remoteRelayDomainEventRTCChange(virConnectPtr conn,
 data.offset = offset;
 
 if (callback->legacy) {
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   REMOTE_PROC_DOMAIN_EVENT_RTC_CHANGE,
   
(xdrproc_t)xdr_remote_domain_event_rtc_change_msg, );
 } else {
 remote_domain_event_callback_rtc_change_msg msg = { 
callback->callbackID,
 data };
 
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   
REMOTE_PROC_DOMAIN_EVENT_CALLBACK_RTC_CHANGE,
   
(xdrproc_t)xdr_remote_domain_event_callback_rtc_change_msg, );
 }
@@ -432,14 +434,14 @@ remoteRelayDomainEventWatchdog(virConnectPtr conn,
 data.action = action;
 
 if (callback->legacy) {
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   REMOTE_PROC_DOMAIN_EVENT_WATCHDOG,
   
(xdrproc_t)xdr_remote_domain_event_watchdog_msg, );
 } else {
 remote_domain_event_callback_watchdog_msg msg = { callback->callbackID,
   data };
 
-remoteDispatchObjectEventSend(callback->client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   
REMOTE_PROC_DOMAIN_EVENT_CALLBACK_WATCHDOG,
   

[libvirt] [PATCH 18/20] remote: Use domainClientEventCallbacks for remoteReplayConnectionClosedEvent

2018-03-08 Thread Marc Hartmayer
This allows us to get rid of another usage of the global variable
remoteProgram.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/remote/remote_daemon_dispatch.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index 9580e854efbe..95940ffdeefe 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -1661,12 +1661,12 @@ remoteRelayDomainQemuMonitorEvent(virConnectPtr conn,
 static
 void remoteRelayConnectionClosedEvent(virConnectPtr conn ATTRIBUTE_UNUSED, int 
reason, void *opaque)
 {
-virNetServerClientPtr client = opaque;
+daemonClientEventCallbackPtr callback = opaque;
 
 VIR_DEBUG("Relaying connection closed event, reason %d", reason);
 
 remote_connect_event_connection_closed_msg msg = { reason };
-remoteDispatchObjectEventSend(client, remoteProgram,
+remoteDispatchObjectEventSend(callback->client, callback->program,
   REMOTE_PROC_CONNECT_EVENT_CONNECTION_CLOSED,
   
(xdrproc_t)xdr_remote_connect_event_connection_closed_msg,
   );
@@ -3814,6 +3814,7 @@ 
remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server ATTRIBUTE_UNUS
virNetMessageErrorPtr rerr)
 {
 int rv = -1;
+daemonClientEventCallbackPtr callback = NULL;
 struct daemonClientPrivate *priv =
 virNetServerClientGetPrivateData(client);
 
@@ -3824,9 +3825,16 @@ 
remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server ATTRIBUTE_UNUS
 goto cleanup;
 }
 
+if (VIR_ALLOC(callback) < 0)
+goto cleanup;
+callback->client = virObjectRef(client);
+callback->program = virObjectRef(remoteProgram);
+/* eventID, callbackID, and legacy are not used */
+callback->eventID = -1;
+callback->callbackID = -1;
 if (virConnectRegisterCloseCallback(priv->conn,
 remoteRelayConnectionClosedEvent,
-client, NULL) < 0)
+callback, remoteEventCallbackFree) < 0)
 goto cleanup;
 
 priv->closeRegistered = true;
@@ -3834,8 +3842,10 @@ 
remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server ATTRIBUTE_UNUS
 
  cleanup:
 virMutexUnlock(>lock);
-if (rv < 0)
+if (rv < 0) {
+remoteEventCallbackFree(callback);
 virNetMessageSaveError(rerr);
+}
 return rv;
 }
 
-- 
2.13.4

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


[libvirt] [PATCH 11/20] test: introduce testDriverCloseInternal

2018-03-08 Thread Marc Hartmayer
Refactor testConnectClose as it's then obvious that conn->privateData
is set to NULL in all cases. In addition, 'testConnectCloseInternal'
can be better reused.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 61 +-
 1 file changed, 35 insertions(+), 26 deletions(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index d450be21704e..fca607f57d51 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1429,10 +1429,36 @@ testConnectAuthenticate(virConnectPtr conn,
 return ret;
 }
 
-static virDrvOpenStatus testConnectOpen(virConnectPtr conn,
-virConnectAuthPtr auth,
-virConfPtr conf ATTRIBUTE_UNUSED,
-unsigned int flags)
+
+static void
+testDriverCloseInternal(testDriverPtr driver)
+{
+bool dflt = false;
+
+if (driver == defaultPrivconn) {
+dflt = true;
+virMutexLock();
+if (--defaultConnections) {
+virMutexUnlock();
+return;
+}
+}
+
+testDriverLock(driver);
+testDriverFree(driver);
+
+if (dflt) {
+defaultPrivconn = NULL;
+virMutexUnlock();
+}
+}
+
+
+static virDrvOpenStatus
+testConnectOpen(virConnectPtr conn,
+virConnectAuthPtr auth,
+virConfPtr conf ATTRIBUTE_UNUSED,
+unsigned int flags)
 {
 int ret;
 
@@ -1473,33 +1499,16 @@ static virDrvOpenStatus testConnectOpen(virConnectPtr 
conn,
 return VIR_DRV_OPEN_SUCCESS;
 }
 
-static int testConnectClose(virConnectPtr conn)
+
+static int
+testConnectClose(virConnectPtr conn)
 {
-testDriverPtr privconn = conn->privateData;
-bool dflt = false;
-
-if (privconn == defaultPrivconn) {
-dflt = true;
-virMutexLock();
-if (--defaultConnections) {
-conn->privateData = NULL;
-virMutexUnlock();
-return 0;
-}
-}
-
-testDriverLock(privconn);
-testDriverFree(privconn);
-
-if (dflt) {
-defaultPrivconn = NULL;
-virMutexUnlock();
-}
-
+testDriverCloseInternal(conn->privateData);
 conn->privateData = NULL;
 return 0;
 }
 
+
 static int testConnectGetVersion(virConnectPtr conn ATTRIBUTE_UNUSED,
  unsigned long *hvVer)
 {
-- 
2.13.4

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


[libvirt] [PATCH 09/20] test: testConnectClose: Set privateData to NULL in all cases

2018-03-08 Thread Marc Hartmayer
Set privateData to NULL also for a connection that uses @defaultConn
as privateData regardless of whether @defaultConn was freed or
not. @defaultConn is shared between multiple connections and it's
ensured that there will be no memory leak by counting references.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index b0ce7d0eea0a..5561d0c2ae70 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1482,6 +1482,7 @@ static int testConnectClose(virConnectPtr conn)
 dflt = true;
 virMutexLock();
 if (--defaultConnections) {
+conn->privateData = NULL;
 virMutexUnlock();
 return 0;
 }
-- 
2.13.4

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


[libvirt] [PATCH 15/20] stream: Access stream->prog instead of a hard-coded global variable

2018-03-08 Thread Marc Hartmayer
Use stream->prog instead of a hard-coded
virNetServerProgram. Especially since these functions are intended as
generic helpers for streams.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Bjoern Walk 
Reviewed-by: Boris Fiuczynski 
---
 src/remote/remote_daemon_stream.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/remote/remote_daemon_stream.c 
b/src/remote/remote_daemon_stream.c
index 4dd3af9e0d59..21f0ecd53844 100644
--- a/src/remote/remote_daemon_stream.c
+++ b/src/remote/remote_daemon_stream.c
@@ -213,7 +213,7 @@ daemonStreamEvent(virStreamPtr st, int events, void *opaque)
 msg->cb = daemonStreamMessageFinished;
 msg->opaque = stream;
 stream->refs++;
-if (virNetServerProgramSendStreamData(remoteProgram,
+if (virNetServerProgramSendStreamData(stream->prog,
   client,
   msg,
   stream->procedure,
@@ -253,7 +253,7 @@ daemonStreamEvent(virStreamPtr st, int events, void *opaque)
 if (!msg) {
 ret = -1;
 } else {
-ret = virNetServerProgramSendStreamError(remoteProgram,
+ret = virNetServerProgramSendStreamError(stream->prog,
  client,
  msg,
  ,
@@ -644,7 +644,7 @@ daemonStreamHandleAbort(virNetServerClientPtr client,
 if (raise_error) {
 virNetMessageError rerr;
 memset(, 0, sizeof(rerr));
-return virNetServerProgramSendReplyError(remoteProgram,
+return virNetServerProgramSendReplyError(stream->prog,
  client,
  msg,
  ,
@@ -839,7 +839,7 @@ daemonStreamHandleRead(virNetServerClientPtr client,
 VIR_DEBUG("rv=%d inData=%d length=%lld", rv, inData, length);
 
 if (rv < 0) {
-if (virNetServerProgramSendStreamError(remoteProgram,
+if (virNetServerProgramSendStreamError(stream->prog,
client,
msg,
,
@@ -856,7 +856,7 @@ daemonStreamHandleRead(virNetServerClientPtr client,
 msg->cb = daemonStreamMessageFinished;
 msg->opaque = stream;
 stream->refs++;
-if (virNetServerProgramSendStreamHole(remoteProgram,
+if (virNetServerProgramSendStreamHole(stream->prog,
   client,
   msg,
   stream->procedure,
@@ -887,7 +887,7 @@ daemonStreamHandleRead(virNetServerClientPtr client,
 /* Should never get this, since we're only called when we know
  * we're readable, but hey things change... */
 } else if (rv < 0) {
-if (virNetServerProgramSendStreamError(remoteProgram,
+if (virNetServerProgramSendStreamError(stream->prog,
client,
msg,
,
@@ -906,7 +906,7 @@ daemonStreamHandleRead(virNetServerClientPtr client,
 msg->cb = daemonStreamMessageFinished;
 msg->opaque = stream;
 stream->refs++;
-if (virNetServerProgramSendStreamData(remoteProgram,
+if (virNetServerProgramSendStreamData(stream->prog,
   client,
   msg,
   stream->procedure,
-- 
2.13.4

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


[libvirt] [PATCH 10/20] test: rename defaultConn to defaultPrivconn

2018-03-08 Thread Marc Hartmayer
Rename the variable @defaultConn to @defaultPrivconn as it doesn't
point to a default connection but to the private data used for the
shared default connection of the test driver.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 5561d0c2ae70..d450be21704e 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -126,7 +126,7 @@ struct _testDriver {
 typedef struct _testDriver testDriver;
 typedef testDriver *testDriverPtr;
 
-static testDriverPtr defaultConn;
+static testDriverPtr defaultPrivconn;
 static int defaultConnections;
 static virMutex defaultLock = VIR_MUTEX_INITIALIZER;
 
@@ -1314,7 +1314,7 @@ testOpenDefault(virConnectPtr conn)
 
 virMutexLock();
 if (defaultConnections++) {
-conn->privateData = defaultConn;
+conn->privateData = defaultPrivconn;
 virMutexUnlock();
 return VIR_DRV_OPEN_SUCCESS;
 }
@@ -1354,7 +1354,7 @@ testOpenDefault(virConnectPtr conn)
 if (testOpenParse(privconn, NULL, ctxt) < 0)
 goto error;
 
-defaultConn = privconn;
+defaultPrivconn = privconn;
 ret = VIR_DRV_OPEN_SUCCESS;
  cleanup:
 virMutexUnlock();
@@ -1478,7 +1478,7 @@ static int testConnectClose(virConnectPtr conn)
 testDriverPtr privconn = conn->privateData;
 bool dflt = false;
 
-if (privconn == defaultConn) {
+if (privconn == defaultPrivconn) {
 dflt = true;
 virMutexLock();
 if (--defaultConnections) {
@@ -1492,7 +1492,7 @@ static int testConnectClose(virConnectPtr conn)
 testDriverFree(privconn);
 
 if (dflt) {
-defaultConn = NULL;
+defaultPrivconn = NULL;
 virMutexUnlock();
 }
 
-- 
2.13.4

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


[libvirt] [PATCH 20/20] remote/rpc: Use virNetServerGetProgram() to determine the program

2018-03-08 Thread Marc Hartmayer
Use virNetServerGetProgram() to determine the virNetServerProgram
instead of using hard coded global variables. This allows us to remove
the global variables @remoteProgram and @qemuProgram as they're now no
longer necessary.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---

Note: I'm not 100% sure that there is no case where the lock for
@client is already held by the thread which is calling
virNetServerGetProgram and thus the lock order would be violated (the
lock order has to be @server -> @client in the violating case it would
be @client -> @server and therefore a deadlock might occur).

---
 src/libvirt_remote.syms |  1 +
 src/remote/remote_daemon.c  |  4 +--
 src/remote/remote_daemon.h  |  3 ---
 src/remote/remote_daemon_dispatch.c | 52 ++---
 src/rpc/gendispatch.pl  |  2 ++
 src/rpc/virnetserver.c  | 23 
 src/rpc/virnetserver.h  |  2 ++
 7 files changed, 56 insertions(+), 31 deletions(-)

diff --git a/src/libvirt_remote.syms b/src/libvirt_remote.syms
index 97e22275b980..c31b16cd5909 100644
--- a/src/libvirt_remote.syms
+++ b/src/libvirt_remote.syms
@@ -120,6 +120,7 @@ virNetServerGetCurrentUnauthClients;
 virNetServerGetMaxClients;
 virNetServerGetMaxUnauthClients;
 virNetServerGetName;
+virNetServerGetProgram;
 virNetServerGetThreadPoolParameters;
 virNetServerHasClients;
 virNetServerNew;
diff --git a/src/remote/remote_daemon.c b/src/remote/remote_daemon.c
index 078430f91c97..64f67ef2fefb 100644
--- a/src/remote/remote_daemon.c
+++ b/src/remote/remote_daemon.c
@@ -71,8 +71,6 @@ VIR_LOG_INIT("daemon.libvirtd");
 #if WITH_SASL
 virNetSASLContextPtr saslCtxt = NULL;
 #endif
-virNetServerProgramPtr remoteProgram = NULL;
-virNetServerProgramPtr qemuProgram = NULL;
 
 volatile bool driversInitialized = false;
 
@@ -1061,6 +1059,8 @@ int main(int argc, char **argv) {
 virNetServerPtr srv = NULL;
 virNetServerPtr srvAdm = NULL;
 virNetServerProgramPtr adminProgram = NULL;
+virNetServerProgramPtr qemuProgram = NULL;
+virNetServerProgramPtr remoteProgram = NULL;
 virNetServerProgramPtr lxcProgram = NULL;
 char *remote_config_file = NULL;
 int statuswrite = -1;
diff --git a/src/remote/remote_daemon.h b/src/remote/remote_daemon.h
index 4467f71da910..93f2e1f531b0 100644
--- a/src/remote/remote_daemon.h
+++ b/src/remote/remote_daemon.h
@@ -82,7 +82,4 @@ struct daemonClientPrivate {
 # if WITH_SASL
 extern virNetSASLContextPtr saslCtxt;
 # endif
-extern virNetServerProgramPtr remoteProgram;
-extern virNetServerProgramPtr qemuProgram;
-
 #endif /* __REMOTE_DAEMON_H__ */
diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index 95940ffdeefe..3dce6195230e 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -3808,9 +3808,9 @@ remoteDispatchNodeDeviceGetParent(virNetServerPtr server 
ATTRIBUTE_UNUSED,
 }
 
 static int
-remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server 
ATTRIBUTE_UNUSED,
+remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server,
virNetServerClientPtr client,
-   virNetMessagePtr msg 
ATTRIBUTE_UNUSED,
+   virNetMessagePtr msg,
virNetMessageErrorPtr rerr)
 {
 int rv = -1;
@@ -3828,7 +3828,7 @@ 
remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server ATTRIBUTE_UNUS
 if (VIR_ALLOC(callback) < 0)
 goto cleanup;
 callback->client = virObjectRef(client);
-callback->program = virObjectRef(remoteProgram);
+callback->program = virObjectRef(virNetServerGetProgram(server, msg));
 /* eventID, callbackID, and legacy are not used */
 callback->eventID = -1;
 callback->callbackID = -1;
@@ -3912,7 +3912,7 @@ remoteDispatchConnectDomainEventRegister(virNetServerPtr 
server ATTRIBUTE_UNUSED
 if (VIR_ALLOC(callback) < 0)
 goto cleanup;
 callback->client = virObjectRef(client);
-callback->program = virObjectRef(remoteProgram);
+callback->program = virObjectRef(virNetServerGetProgram(server, msg));
 callback->eventID = VIR_DOMAIN_EVENT_ID_LIFECYCLE;
 callback->callbackID = -1;
 callback->legacy = true;
@@ -4110,9 +4110,9 @@ remoteDispatchDomainGetState(virNetServerPtr server 
ATTRIBUTE_UNUSED,
  * VIR_DRV_SUPPORTS_FEATURE(VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK),
  * and must not mix the two styles.  */
 static int
-remoteDispatchConnectDomainEventRegisterAny(virNetServerPtr server 
ATTRIBUTE_UNUSED,
+remoteDispatchConnectDomainEventRegisterAny(virNetServerPtr server,
 virNetServerClientPtr client,
-virNetMessagePtr msg 
ATTRIBUTE_UNUSED,
+  

[libvirt] [PATCH 03/20] virConnect(Un)RegisterCloseCallback: Throw an error in case the API is not supported

2018-03-08 Thread Marc Hartmayer
Report an error in case the driver does not support
connect(Un)registerCloseCallback. The commit 'close callback: move it
to driver' (88f09b75eb99) moved the responsibility for the close
callback to the driver. But if the driver doesn't support the
connectRegisterCloseCallback API this function does nothing, even no
unsupported error report. The only case where an error is reported is
when the API is supported but the call fails. The same behavior
applies to virConnectUnregisterCloseCallback.

This behavior is not intended as there are many use cases of this API
where the state of for example allocations depends on the result of
these functions.

To keep the behavior of virsh as before it must silently ignore
unsupported error for virConnectRegisterCloseCallback. For the remote
driver this change wouldn't be needed, but for the byhve driver, for
example. Otherwise the user would see the error message that virsh was
unable to register a disconnect callback.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/libvirt-host.c | 24 ++--
 tools/virsh.c  | 11 +--
 2 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/src/libvirt-host.c b/src/libvirt-host.c
index 7ff7407a0874..bfa104b39918 100644
--- a/src/libvirt-host.c
+++ b/src/libvirt-host.c
@@ -1221,12 +1221,14 @@ virConnectRegisterCloseCallback(virConnectPtr conn,
 virCheckConnectReturn(conn, -1);
 virCheckNonNullArgGoto(cb, error);
 
-if (conn->driver->connectRegisterCloseCallback &&
-conn->driver->connectRegisterCloseCallback(conn, cb, opaque, freecb) < 
0)
-goto error;
-
-return 0;
+if (conn->driver->connectRegisterCloseCallback) {
+int ret = conn->driver->connectRegisterCloseCallback(conn, cb, opaque, 
freecb);
+if (ret < 0)
+goto error;
+return ret;
+}
 
+virReportUnsupportedError();
  error:
 virDispatchError(conn);
 return -1;
@@ -1256,12 +1258,14 @@ virConnectUnregisterCloseCallback(virConnectPtr conn,
 virCheckConnectReturn(conn, -1);
 virCheckNonNullArgGoto(cb, error);
 
-if (conn->driver->connectUnregisterCloseCallback &&
-conn->driver->connectUnregisterCloseCallback(conn, cb) < 0)
-goto error;
-
-return 0;
+if (conn->driver->connectUnregisterCloseCallback) {
+int ret = conn->driver->connectUnregisterCloseCallback(conn, cb);
+if (ret < 0)
+goto error;
+return ret;
+}
 
+virReportUnsupportedError();
  error:
 virDispatchError(conn);
 return -1;
diff --git a/tools/virsh.c b/tools/virsh.c
index 5f8352e861d3..2df1197252b3 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -256,8 +256,15 @@ virshReconnect(vshControl *ctl, const char *name, bool 
readonly, bool force)
 priv->readonly = readonly;
 
 if (virConnectRegisterCloseCallback(priv->conn, virshCatchDisconnect,
-ctl, NULL) < 0)
-vshError(ctl, "%s", _("Unable to register disconnect callback"));
+ctl, NULL) < 0) {
+virErrorPtr error = virGetLastError();
+if (error && error->code == VIR_ERR_NO_SUPPORT) {
+/* silently ignore the unsupported error */
+virResetLastError();
+} else {
+vshError(ctl, "%s", _("Unable to register disconnect 
callback"));
+}
+}
 if (connected && !force)
 vshError(ctl, "%s", _("Reconnected to the hypervisor"));
 }
-- 
2.13.4

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


[libvirt] [PATCH 02/20] remote: Don't hard code the feature VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK as available

2018-03-08 Thread Marc Hartmayer
Don't assume that the feature VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK is
available for every driver used for the connection.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Bjoern Walk 
Reviewed-by: Boris Fiuczynski 
---
 src/remote/remote_daemon_dispatch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index 82f6400ca49d..bf6c00348a5e 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -4667,7 +4667,6 @@ static int 
remoteDispatchConnectSupportsFeature(virNetServerPtr server ATTRIBUTE
 switch ((virDrvFeature) args->feature) {
 case VIR_DRV_FEATURE_FD_PASSING:
 case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
-case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
 supported = 1;
 break;
 case VIR_DRV_FEATURE_MIGRATION_V1:
@@ -4681,6 +4680,7 @@ static int 
remoteDispatchConnectSupportsFeature(virNetServerPtr server ATTRIBUTE
 case VIR_DRV_FEATURE_XML_MIGRATABLE:
 case VIR_DRV_FEATURE_MIGRATION_OFFLINE:
 case VIR_DRV_FEATURE_MIGRATION_PARAMS:
+case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
 default:
 if ((supported = virConnectSupportsFeature(priv->conn, args->feature)) 
< 0)
 goto cleanup;
-- 
2.13.4

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


[libvirt] [PATCH 13/20] test: Convert testDriver to virObjectLockable

2018-03-08 Thread Marc Hartmayer
The test driver state (@testDriver) uses it's own reference counting
and locking implementation. Instead of doing that, convert @testDriver
into a virObjectLockable and use the provided functionalities.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 207 ++---
 1 file changed, 94 insertions(+), 113 deletions(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 3b55453efe00..f1dd11867143 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -94,7 +94,7 @@ typedef struct _testAuth testAuth;
 typedef struct _testAuth *testAuthPtr;
 
 struct _testDriver {
-virMutex lock;
+virObjectLockable parent;
 
 virNodeInfo nodeInfo;
 virInterfaceObjListPtr ifaces;
@@ -127,9 +127,22 @@ typedef struct _testDriver testDriver;
 typedef testDriver *testDriverPtr;
 
 static testDriverPtr defaultPrivconn;
-static int defaultConnections;
 static virMutex defaultLock = VIR_MUTEX_INITIALIZER;
 
+static virClassPtr testDriverClass;
+static void testDriverDispose(void *obj);
+static int testDriverOnceInit(void)
+{
+if (!(testDriverClass = virClassNew(virClassForObjectLockable(),
+"testDriver",
+sizeof(testDriver),
+testDriverDispose)))
+return -1;
+
+return 0;
+}
+VIR_ONCE_GLOBAL_INIT(testDriver)
+
 #define TEST_MODEL "i686"
 #define TEST_EMULATOR "/usr/bin/test-hv"
 
@@ -145,10 +158,9 @@ static const virNodeInfo defaultNodeInfo = {
 };
 
 static void
-testDriverFree(testDriverPtr driver)
+testDriverDispose(void *obj)
 {
-if (!driver)
-return;
+testDriverPtr driver = obj;
 
 virObjectUnref(driver->caps);
 virObjectUnref(driver->xmlopt);
@@ -159,23 +171,9 @@ testDriverFree(testDriverPtr driver)
 virObjectUnref(driver->pools);
 virObjectUnref(driver->eventState);
 virObjectUnref(driver->closeCallback);
-virMutexUnlock(>lock);
-virMutexDestroy(>lock);
-
-VIR_FREE(driver);
 }
 
 
-static void testDriverLock(testDriverPtr driver)
-{
-virMutexLock(>lock);
-}
-
-static void testDriverUnlock(testDriverPtr driver)
-{
-virMutexUnlock(>lock);
-}
-
 static void testObjectEventQueue(testDriverPtr driver,
  virObjectEventPtr event)
 {
@@ -408,14 +406,11 @@ testDriverNew(void)
 testDriverPtr ret;
 virConnectCloseCallbackDataPtr closeCallback;
 
-if (VIR_ALLOC(ret) < 0)
+if (testDriverInitialize() < 0)
 return NULL;
 
-if (virMutexInit(>lock) < 0) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
-   "%s", _("cannot initialize mutex"));
-goto error;
-}
+if (!(ret = virObjectLockableNew(testDriverClass)))
+return NULL;
 
 if (!(ret->xmlopt = virDomainXMLOptionNew(NULL, NULL, , NULL, NULL)) ||
 !(ret->eventState = virObjectEventStateNew()) ||
@@ -437,7 +432,7 @@ testDriverNew(void)
 return ret;
 
  error:
-testDriverFree(ret);
+virObjectUnref(ret);
 return NULL;
 }
 
@@ -1271,7 +1266,7 @@ testOpenFromFile(virConnectPtr conn, const char *file)
 if (!(privconn = testDriverNew()))
 return VIR_DRV_OPEN_ERROR;
 
-testDriverLock(privconn);
+virObjectLock(privconn);
 conn->privateData = privconn;
 
 if (!(privconn->caps = testBuildCapabilities(conn)))
@@ -1288,14 +1283,14 @@ testOpenFromFile(virConnectPtr conn, const char *file)
 
 xmlXPathFreeContext(ctxt);
 xmlFreeDoc(doc);
-testDriverUnlock(privconn);
+virObjectUnlock(privconn);
 
 return VIR_DRV_OPEN_SUCCESS;
 
  error:
 xmlXPathFreeContext(ctxt);
 xmlFreeDoc(doc);
-testDriverFree(privconn);
+virObjectUnref(privconn);
 conn->privateData = NULL;
 return VIR_DRV_OPEN_ERROR;
 }
@@ -1313,8 +1308,8 @@ testOpenDefault(virConnectPtr conn)
 size_t i;
 
 virMutexLock();
-if (defaultConnections++) {
-conn->privateData = defaultPrivconn;
+if (defaultPrivconn) {
+conn->privateData = virObjectRef(defaultPrivconn);
 virMutexUnlock();
 return VIR_DRV_OPEN_SUCCESS;
 }
@@ -1363,9 +1358,8 @@ testOpenDefault(virConnectPtr conn)
 return ret;
 
  error:
-testDriverFree(privconn);
+virObjectUnref(privconn);
 conn->privateData = NULL;
-defaultConnections--;
 ret = VIR_DRV_OPEN_ERROR;
 goto cleanup;
 }
@@ -1379,9 +1373,9 @@ testConnectAuthenticate(virConnectPtr conn,
 ssize_t i;
 char *username = NULL, *password = NULL;
 
-testDriverLock(privconn);
+virObjectLock(privconn);
 if (privconn->numAuths == 0) {
-testDriverUnlock(privconn);
+virObjectUnlock(privconn);
 return 0;
 }
 
@@ -1423,7 +1417,7 @@ testConnectAuthenticate(virConnectPtr conn,
 
 ret = 0;
  cleanup:
-testDriverUnlock(privconn);
+

[libvirt] [PATCH 19/20] rpc: Introduce virNetServerGetProgramLocked helper function

2018-03-08 Thread Marc Hartmayer
This patch introduces virNetServerGetProgramLocked. It's a function to
determine which program has to be used for a given @msg. This function
will be reused in the next patch.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/rpc/virnetserver.c | 31 ---
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/src/rpc/virnetserver.c b/src/rpc/virnetserver.c
index 204f425264fa..4cd42ad7fd40 100644
--- a/src/rpc/virnetserver.c
+++ b/src/rpc/virnetserver.c
@@ -182,6 +182,29 @@ static void virNetServerHandleJob(void *jobOpaque, void 
*opaque)
 VIR_FREE(job);
 }
 
+
+/**
+ * virNetServerGetProgramLocked:
+ * @srv: server (must be locked by the caller)
+ * @msg: message
+ *
+ * Searches @srv for the right program for a given message @msg.
+ *
+ * Returns a pointer to the server program or NULL if not found.
+ */
+static virNetServerProgramPtr
+virNetServerGetProgramLocked(virNetServerPtr srv,
+ virNetMessagePtr msg)
+{
+size_t i;
+for (i = 0; i < srv->nprograms; i++) {
+if (virNetServerProgramMatches(srv->programs[i], msg))
+return srv->programs[i];
+}
+return NULL;
+}
+
+
 static int virNetServerDispatchNewMessage(virNetServerClientPtr client,
   virNetMessagePtr msg,
   void *opaque)
@@ -189,19 +212,13 @@ static int 
virNetServerDispatchNewMessage(virNetServerClientPtr client,
 virNetServerPtr srv = opaque;
 virNetServerProgramPtr prog = NULL;
 unsigned int priority = 0;
-size_t i;
 int ret = -1;
 
 VIR_DEBUG("server=%p client=%p message=%p",
   srv, client, msg);
 
 virObjectLock(srv);
-for (i = 0; i < srv->nprograms; i++) {
-if (virNetServerProgramMatches(srv->programs[i], msg)) {
-prog = srv->programs[i];
-break;
-}
-}
+prog = virNetServerGetProgramLocked(srv, msg);
 
 if (srv->workers) {
 virNetServerJobPtr job;
-- 
2.13.4

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


[libvirt] [PATCH 06/20] test: testOpenDefault: introduce cleanup path

2018-03-08 Thread Marc Hartmayer
The two code paths have some cleanup in common so lets refactor it.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 2773f5c758c8..e7307fddad4a 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1306,6 +1306,7 @@ testOpenFromFile(virConnectPtr conn, const char *file)
 static int
 testOpenDefault(virConnectPtr conn)
 {
+int ret;
 testDriverPtr privconn = NULL;
 xmlDocPtr doc = NULL;
 xmlXPathContextPtr ctxt = NULL;
@@ -1354,21 +1355,19 @@ testOpenDefault(virConnectPtr conn)
 goto error;
 
 defaultConn = privconn;
-
+ret = VIR_DRV_OPEN_SUCCESS;
+ cleanup:
+virMutexUnlock();
 xmlXPathFreeContext(ctxt);
 xmlFreeDoc(doc);
-virMutexUnlock();
-
-return VIR_DRV_OPEN_SUCCESS;
+return ret;
 
  error:
 testDriverFree(privconn);
-xmlXPathFreeContext(ctxt);
-xmlFreeDoc(doc);
 conn->privateData = NULL;
 defaultConnections--;
-virMutexUnlock();
-return VIR_DRV_OPEN_ERROR;
+ret = VIR_DRV_OPEN_ERROR;
+goto cleanup;
 }
 
 static int
-- 
2.13.4

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


[libvirt] [PATCH 07/20] test: testOpenFromFile: return VIR_DRV_OPEN_SUCCESS in case of success

2018-03-08 Thread Marc Hartmayer
Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index e7307fddad4a..388407d4371f 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1290,7 +1290,7 @@ testOpenFromFile(virConnectPtr conn, const char *file)
 xmlFreeDoc(doc);
 testDriverUnlock(privconn);
 
-return 0;
+return VIR_DRV_OPEN_SUCCESS;
 
  error:
 xmlXPathFreeContext(ctxt);
-- 
2.13.4

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


[libvirt] [PATCH 12/20] test: fix error path in testConnectOpen

2018-03-08 Thread Marc Hartmayer
In case of an error do the cleanup of the private data of the
connection.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index fca607f57d51..3b55453efe00 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1493,8 +1493,11 @@ testConnectOpen(virConnectPtr conn,
 return ret;
 
 /* Fake authentication. */
-if (testConnectAuthenticate(conn, auth) < 0)
+if (testConnectAuthenticate(conn, auth) < 0) {
+testDriverCloseInternal(conn->privateData);
+conn->privateData = NULL;
 return VIR_DRV_OPEN_ERROR;
+}
 
 return VIR_DRV_OPEN_SUCCESS;
 }
-- 
2.13.4

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


[libvirt] [PATCH 08/20] test: testConnectAuthenticate: Take the lock when accessing mutable values

2018-03-08 Thread Marc Hartmayer
Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 388407d4371f..b0ce7d0eea0a 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -1379,8 +1379,11 @@ testConnectAuthenticate(virConnectPtr conn,
 ssize_t i;
 char *username = NULL, *password = NULL;
 
-if (privconn->numAuths == 0)
+testDriverLock(privconn);
+if (privconn->numAuths == 0) {
+testDriverUnlock(privconn);
 return 0;
+}
 
 /* Authentication is required because the test XML contains a
  * non-empty  section.  First we must ask for a username.
@@ -1420,6 +1423,7 @@ testConnectAuthenticate(virConnectPtr conn,
 
 ret = 0;
  cleanup:
+testDriverUnlock(privconn);
 VIR_FREE(username);
 VIR_FREE(password);
 return ret;
-- 
2.13.4

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


[libvirt] [PATCH 01/20] driver: Add typedef for the anonymous enum used for driver features

2018-03-08 Thread Marc Hartmayer
Add typedef for the anonymous enum used for the driver features. This
allows the usage of the type in a switch statement and taking
advantage of the compilers feature to detect uncovered cases.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/esx/esx_driver.c| 18 --
 src/libvirt_internal.h  |  4 ++--
 src/libxl/libxl_driver.c| 13 -
 src/lxc/lxc_driver.c| 24 +++-
 src/openvz/openvz_driver.c  | 15 ++-
 src/qemu/qemu_driver.c  |  8 +++-
 src/remote/remote_daemon_dispatch.c | 19 ---
 src/vz/vz_driver.c  | 15 ++-
 src/xen/xen_driver.c| 15 ++-
 9 files changed, 114 insertions(+), 17 deletions(-)

diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index b065cdc51323..927267f1cc98 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -1122,7 +1122,7 @@ esxConnectSupportsFeature(virConnectPtr conn, int feature)
 esxPrivate *priv = conn->privateData;
 esxVI_Boolean supportsVMotion = esxVI_Boolean_Undefined;
 
-switch (feature) {
+switch ((virDrvFeature) feature) {
   case VIR_DRV_FEATURE_MIGRATION_V1:
 supportsVMotion = esxSupportsVMotion(priv);
 
@@ -1133,7 +1133,21 @@ esxConnectSupportsFeature(virConnectPtr conn, int 
feature)
 return priv->vCenter &&
supportsVMotion == esxVI_Boolean_True ? 1 : 0;
 
-  default:
+case VIR_DRV_FEATURE_FD_PASSING:
+case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION:
+case VIR_DRV_FEATURE_MIGRATION_DIRECT:
+case VIR_DRV_FEATURE_MIGRATION_OFFLINE:
+case VIR_DRV_FEATURE_MIGRATION_P2P:
+case VIR_DRV_FEATURE_MIGRATION_PARAMS:
+case VIR_DRV_FEATURE_MIGRATION_V2:
+case VIR_DRV_FEATURE_MIGRATION_V3:
+case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE:
+case VIR_DRV_FEATURE_REMOTE:
+case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
+case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
+case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
+case VIR_DRV_FEATURE_XML_MIGRATABLE:
+default:
 return 0;
 }
 }
diff --git a/src/libvirt_internal.h b/src/libvirt_internal.h
index 62f490a7dfd5..0e008a65518d 100644
--- a/src/libvirt_internal.h
+++ b/src/libvirt_internal.h
@@ -45,7 +45,7 @@ int virStateStop(void);
  * feature.  Queries for VIR_DRV_FEATURE_PROGRAM* features are answered
  * directly by the RPC layer and not by the real driver.
  */
-enum {
+typedef enum {
 /* Driver supports V1-style virDomainMigrate, ie. domainMigratePrepare/
  * domainMigratePerform/domainMigrateFinish.
  */
@@ -123,7 +123,7 @@ enum {
  * Support for driver close callback rpc
  */
 VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK = 15,
-};
+} virDrvFeature;
 
 
 int virConnectSupportsFeature(virConnectPtr conn, int feature);
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index c3616a86d7f4..562966cc2062 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5684,12 +5684,23 @@ libxlConnectSupportsFeature(virConnectPtr conn, int 
feature)
 if (virConnectSupportsFeatureEnsureACL(conn) < 0)
 return -1;
 
-switch (feature) {
+switch ((virDrvFeature) feature) {
 case VIR_DRV_FEATURE_MIGRATION_V3:
 case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
 case VIR_DRV_FEATURE_MIGRATION_PARAMS:
 case VIR_DRV_FEATURE_MIGRATION_P2P:
 return 1;
+case VIR_DRV_FEATURE_FD_PASSING:
+case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION:
+case VIR_DRV_FEATURE_MIGRATION_DIRECT:
+case VIR_DRV_FEATURE_MIGRATION_OFFLINE:
+case VIR_DRV_FEATURE_MIGRATION_V1:
+case VIR_DRV_FEATURE_MIGRATION_V2:
+case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE:
+case VIR_DRV_FEATURE_REMOTE:
+case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
+case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
+case VIR_DRV_FEATURE_XML_MIGRATABLE:
 default:
 return 0;
 }
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
index fa6fc4643ee2..4f6b93bdbd30 100644
--- a/src/lxc/lxc_driver.c
+++ b/src/lxc/lxc_driver.c
@@ -1793,11 +1793,25 @@ lxcConnectSupportsFeature(virConnectPtr conn, int 
feature)
 if (virConnectSupportsFeatureEnsureACL(conn) < 0)
 return -1;
 
-switch (feature) {
-case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
-return 1;
-default:
-return 0;
+switch ((virDrvFeature) feature) {
+case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
+return 1;
+case VIR_DRV_FEATURE_FD_PASSING:
+case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION:
+case VIR_DRV_FEATURE_MIGRATION_DIRECT:
+case VIR_DRV_FEATURE_MIGRATION_OFFLINE:
+case VIR_DRV_FEATURE_MIGRATION_P2P:
+case VIR_DRV_FEATURE_MIGRATION_PARAMS:
+case VIR_DRV_FEATURE_MIGRATION_V1:
+case VIR_DRV_FEATURE_MIGRATION_V2:
+case 

[libvirt] [PATCH 00/20] Fix virConnect(Un)RegisterCloseCallback and get rid of global variables

2018-03-08 Thread Marc Hartmayer
The first part of this patch series fixes the behavior of
virConnectSupportsFeatures, virConnect(Un)RegisterCloseCallback, and
implements these features in the test driver. This results in a better
code coverage of our test suite.

The subsequent patches remove the need to have the global variables
'qemuProgram', 'adminProgram', 'lxcProgram, and 'remoteProgram' in
remote_daemon.[ch]. They only work in combination with the fixed
behavior of virConnectSupportsFeatures and
virConnect(Un)RegisterCloseCallback.

Marc Hartmayer (20):
  driver: Add typedef for the anonymous enum used for driver features
  remote: Don't hard code the feature
VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK as available
  virConnect(Un)RegisterCloseCallback: Throw an error in case the API is
not supported
  test: Implement virConnectSupportsFeature
  test: Implement virConnect(Un)RegisterCloseCallback
  test: testOpenDefault: introduce cleanup path
  test: testOpenFromFile: return VIR_DRV_OPEN_SUCCESS in case of success
  test: testConnectAuthenticate: Take the lock when accessing mutable
values
  test: testConnectClose: Set privateData to NULL in all cases
  test: rename defaultConn to defaultPrivconn
  test: introduce testDriverCloseInternal
  test: fix error path in testConnectOpen
  test: Convert testDriver to virObjectLockable
  remote: remove unneeded global variables
  stream: Access stream->prog instead of a hard-coded global variable
  remote: Set eventID explicitly to an invalid value
  remote: Add the information which program has to be used to
daemonClientEventCallback
  remote: Use domainClientEventCallbacks for
remoteReplayConnectionClosedEvent
  rpc: Introduce virNetServerGetProgramLocked helper function
  remote/rpc: Use virNetServerGetProgram() to determine the program

 src/esx/esx_driver.c|  18 +-
 src/libvirt-host.c  |  24 +--
 src/libvirt_internal.h  |   4 +-
 src/libvirt_remote.syms |   1 +
 src/libxl/libxl_driver.c|  13 +-
 src/lxc/lxc_driver.c|  24 ++-
 src/openvz/openvz_driver.c  |  15 +-
 src/qemu/qemu_driver.c  |   8 +-
 src/remote/remote_daemon.c  |   8 +-
 src/remote/remote_daemon.h  |   3 -
 src/remote/remote_daemon_dispatch.c | 182 +++
 src/remote/remote_daemon_stream.c   |  14 +-
 src/rpc/gendispatch.pl  |   2 +
 src/rpc/virnetserver.c  |  54 +-
 src/rpc/virnetserver.h  |   2 +
 src/test/test_driver.c  | 339 ++--
 src/vz/vz_driver.c  |  15 +-
 src/xen/xen_driver.c|  15 +-
 tools/virsh.c   |  11 +-
 19 files changed, 504 insertions(+), 248 deletions(-)

-- 
2.13.4

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


[libvirt] [PATCH 04/20] test: Implement virConnectSupportsFeature

2018-03-08 Thread Marc Hartmayer
Implement virConnectSupportsFeature for the test driver as this API is
used by various API functions (the functions usually use the macro
VIR_DRV_SUPPORTS_FEATURE for calling virConnectSupportsFeature).

Signed-off-by: Marc Hartmayer 
Reviewed-by: Bjoern Walk 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 043caa976274..203358c7017f 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -6829,6 +6829,32 @@ testDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
 }
 
 
+static int
+testConnectSupportsFeature(virConnectPtr conn ATTRIBUTE_UNUSED,
+   int feature)
+{
+switch ((virDrvFeature) feature) {
+case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
+return 1;
+case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
+case VIR_DRV_FEATURE_FD_PASSING:
+case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION:
+case VIR_DRV_FEATURE_MIGRATION_DIRECT:
+case VIR_DRV_FEATURE_MIGRATION_OFFLINE:
+case VIR_DRV_FEATURE_MIGRATION_P2P:
+case VIR_DRV_FEATURE_MIGRATION_PARAMS:
+case VIR_DRV_FEATURE_MIGRATION_V1:
+case VIR_DRV_FEATURE_MIGRATION_V2:
+case VIR_DRV_FEATURE_MIGRATION_V3:
+case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE:
+case VIR_DRV_FEATURE_REMOTE:
+case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
+case VIR_DRV_FEATURE_XML_MIGRATABLE:
+default:
+return 0;
+}
+}
+
 
 static virHypervisorDriver testHypervisorDriver = {
 .name = "Test",
@@ -6837,6 +6863,7 @@ static virHypervisorDriver testHypervisorDriver = {
 .connectGetVersion = testConnectGetVersion, /* 0.1.1 */
 .connectGetHostname = testConnectGetHostname, /* 0.6.3 */
 .connectGetMaxVcpus = testConnectGetMaxVcpus, /* 0.3.2 */
+.connectSupportsFeature = testConnectSupportsFeature, /* 4.2.0 */
 .nodeGetInfo = testNodeGetInfo, /* 0.1.1 */
 .nodeGetCPUStats = testNodeGetCPUStats, /* 2.3.0 */
 .nodeGetFreeMemory = testNodeGetFreeMemory, /* 2.3.0 */
-- 
2.13.4

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


[libvirt] [PATCH 16/20] remote: Set eventID explicitly to an invalid value

2018-03-08 Thread Marc Hartmayer
Set the eventID for remoteRelayDomainQemuMonitorEvent explicitly to an
invalid value. Although the value is not used by
remoteRelayDomainQemuMonitorEvent, but it might be less prone to
errors for further refactorings.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Bjoern Walk 
Reviewed-by: Boris Fiuczynski 
---
 src/remote/remote_daemon_dispatch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index bf6c00348a5e..ff26574c9f6b 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -6215,6 +6215,7 @@ 
qemuDispatchConnectDomainMonitorEventRegister(virNetServerPtr server ATTRIBUTE_U
 if (VIR_ALLOC(callback) < 0)
 goto cleanup;
 callback->client = virObjectRef(client);
+callback->eventID = -1;
 callback->callbackID = -1;
 ref = callback;
 if (VIR_APPEND_ELEMENT(priv->qemuEventCallbacks,
-- 
2.13.4

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


[libvirt] [PATCH 14/20] remote: remove unneeded global variables

2018-03-08 Thread Marc Hartmayer
Remove unneeded global variables and convert them into local variables
where they're needed.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Bjoern Walk 
Reviewed-by: Boris Fiuczynski 
---
 src/remote/remote_daemon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/remote/remote_daemon.c b/src/remote/remote_daemon.c
index f8082f62f698..078430f91c97 100644
--- a/src/remote/remote_daemon.c
+++ b/src/remote/remote_daemon.c
@@ -72,9 +72,7 @@ VIR_LOG_INIT("daemon.libvirtd");
 virNetSASLContextPtr saslCtxt = NULL;
 #endif
 virNetServerProgramPtr remoteProgram = NULL;
-virNetServerProgramPtr adminProgram = NULL;
 virNetServerProgramPtr qemuProgram = NULL;
-virNetServerProgramPtr lxcProgram = NULL;
 
 volatile bool driversInitialized = false;
 
@@ -1062,6 +1060,8 @@ int main(int argc, char **argv) {
 virNetDaemonPtr dmn = NULL;
 virNetServerPtr srv = NULL;
 virNetServerPtr srvAdm = NULL;
+virNetServerProgramPtr adminProgram = NULL;
+virNetServerProgramPtr lxcProgram = NULL;
 char *remote_config_file = NULL;
 int statuswrite = -1;
 int ret = 1;
-- 
2.13.4

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


[libvirt] [PATCH 05/20] test: Implement virConnect(Un)RegisterCloseCallback

2018-03-08 Thread Marc Hartmayer
Implement the hypervisor APIs virConnectRegisterCloseCallback and
virConnectUnregisterCloseCallbacks and mark this feature as supported
in testConnectSupportsFeature. This increases test test coverage of
the test suite as then the testConnectRegisterCloseCallback and
testConnectUnregisterCloseCallback (which are almost identical to the
implementations of the remote and vz driver) will be called by the
virsh tests.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/test/test_driver.c | 63 +-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 203358c7017f..2773f5c758c8 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -121,6 +121,7 @@ struct _testDriver {
 virDomainObjListPtr domains;
 virNetworkObjListPtr networks;
 virObjectEventStatePtr eventState;
+virConnectCloseCallbackDataPtr closeCallback;
 };
 typedef struct _testDriver testDriver;
 typedef testDriver *testDriverPtr;
@@ -157,6 +158,7 @@ testDriverFree(testDriverPtr driver)
 virObjectUnref(driver->ifaces);
 virObjectUnref(driver->pools);
 virObjectUnref(driver->eventState);
+virObjectUnref(driver->closeCallback);
 virMutexUnlock(>lock);
 virMutexDestroy(>lock);
 
@@ -404,6 +406,7 @@ testDriverNew(void)
 .free = testDomainDefNamespaceFree,
 };
 testDriverPtr ret;
+virConnectCloseCallbackDataPtr closeCallback;
 
 if (VIR_ALLOC(ret) < 0)
 return NULL;
@@ -423,6 +426,12 @@ testDriverNew(void)
 !(ret->pools = virStoragePoolObjListNew()))
 goto error;
 
+closeCallback = virNewConnectCloseCallbackData();
+if (!closeCallback)
+goto error;
+
+ret->closeCallback = closeCallback;
+
 virAtomicIntSet(>nextDomID, 1);
 
 return ret;
@@ -6834,9 +6843,9 @@ testConnectSupportsFeature(virConnectPtr conn 
ATTRIBUTE_UNUSED,
int feature)
 {
 switch ((virDrvFeature) feature) {
+case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
 case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
 return 1;
-case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
 case VIR_DRV_FEATURE_FD_PASSING:
 case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION:
 case VIR_DRV_FEATURE_MIGRATION_DIRECT:
@@ -6855,6 +6864,56 @@ testConnectSupportsFeature(virConnectPtr conn 
ATTRIBUTE_UNUSED,
 }
 }
 
+static int
+testConnectRegisterCloseCallback(virConnectPtr conn,
+ virConnectCloseFunc cb,
+ void *opaque,
+ virFreeCallback freecb)
+{
+testDriverPtr priv = conn->privateData;
+int ret = -1;
+
+testDriverLock(priv);
+
+if (virConnectCloseCallbackDataGetCallback(priv->closeCallback) != NULL) {
+virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+   _("A close callback is already registered"));
+goto cleanup;
+}
+
+virConnectCloseCallbackDataRegister(priv->closeCallback, conn, cb,
+opaque, freecb);
+ret = 0;
+
+ cleanup:
+testDriverUnlock(priv);
+return ret;
+}
+
+
+static int
+testConnectUnregisterCloseCallback(virConnectPtr conn,
+   virConnectCloseFunc cb)
+{
+testDriverPtr priv = conn->privateData;
+int ret = -1;
+
+testDriverLock(priv);
+
+if (virConnectCloseCallbackDataGetCallback(priv->closeCallback) != cb) {
+virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+   _("A different callback was requested"));
+goto cleanup;
+}
+
+virConnectCloseCallbackDataUnregister(priv->closeCallback, cb);
+ret = 0;
+
+ cleanup:
+testDriverUnlock(priv);
+return ret;
+}
+
 
 static virHypervisorDriver testHypervisorDriver = {
 .name = "Test",
@@ -6863,7 +6922,9 @@ static virHypervisorDriver testHypervisorDriver = {
 .connectGetVersion = testConnectGetVersion, /* 0.1.1 */
 .connectGetHostname = testConnectGetHostname, /* 0.6.3 */
 .connectGetMaxVcpus = testConnectGetMaxVcpus, /* 0.3.2 */
+.connectRegisterCloseCallback = testConnectRegisterCloseCallback, /* 4.2.0 
*/
 .connectSupportsFeature = testConnectSupportsFeature, /* 4.2.0 */
+.connectUnregisterCloseCallback = testConnectUnregisterCloseCallback, /* 
4.2.0 */
 .nodeGetInfo = testNodeGetInfo, /* 0.1.1 */
 .nodeGetCPUStats = testNodeGetCPUStats, /* 2.3.0 */
 .nodeGetFreeMemory = testNodeGetFreeMemory, /* 2.3.0 */
-- 
2.13.4

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


[libvirt] [PATCH] Add kubevirt blog to planet virttools

2018-03-08 Thread Fabian Deutsch
Signed-off-by: Fabian Deutsch 
---
 updater/virt-tools/config.ini | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/updater/virt-tools/config.ini b/updater/virt-tools/config.ini
index ff1bff3..4b55c6c 100644
--- a/updater/virt-tools/config.ini
+++ b/updater/virt-tools/config.ini
@@ -179,3 +179,6 @@ name = Marcin Juszkiewicz

 [https://dummdida.tumblr.com/tagged/virtualization/rss]
 name = Fabian Deutsch
+
+[http://blog.kubevirt.io/rss/]
+name = KubeVirt Blog
-- 
2.13.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Add Fabian Deutsch to Planet virttools

2018-03-08 Thread Fabian Deutsch
… who is occasionally writing about KubeVirt

Signed-off-by: Fabian Deutsch 
---
 updater/virt-tools/config.ini | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/updater/virt-tools/config.ini b/updater/virt-tools/config.ini
index a56d3b7..ff1bff3 100644
--- a/updater/virt-tools/config.ini
+++ b/updater/virt-tools/config.ini
@@ -176,3 +176,6 @@ faceheight = 80

 [https://marcin.juszkiewicz.com.pl/tag/virtualization/feed/]
 name = Marcin Juszkiewicz
+
+[https://dummdida.tumblr.com/tagged/virtualization/rss]
+name = Fabian Deutsch
-- 
2.13.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

2018-03-08 Thread Laszlo Ersek
(
Ard, the thread starts here:

http://mid.mail-archive.com/20180307144951.d75lo5rgzi2vf27z@eukaryote
)

On 03/07/18 15:49, Kashyap Chamarthy wrote:
> Problem background
> --
> 
> The various OVMF binary file names and paths are slightly different[+]
> for each Linux distribution.  And each high-level management tool
> (libguestfs, oVirt, `virt-manager` and OpenStack Nova) is inventing its
> own approach to detect and configure the said OVMF files.  This email
> thread is about arriving at some common understanding to make this a bit
> more "unified" by addressing these needs in QEMU and libvirt.

I've read Dan's message <20180307151836.gk20...@redhat.com> and Gerd's
messages <20180308075245.lgzredyhn2paa...@sirius.home.kraxel.org>,
<20180308074507.nwho4tddsoxb3...@sirius.home.kraxel.org>.

Those seem to cover everything, I don't have anything to add wrt.
purpose, use case, flexibility etc.

I suggest (or agree) that the property list be composed of free-form
name=value pairs (at least conceptually). I understand Gerd is proposing
a QAPI schema for this, so maybe do { property_name : "foo",
property_value : "bar" }, or similar. The registry of properties (names,
possible values, meanings) should be kept separate (although possibly
still under QEMU).

For OVMF (x86), I guess the initial set of properties should come from
the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
might grow or change incompatibly over time, so this is just a raw
starter idea.)

We have:

(0) ARCH (one of IA32, IA32X64, X64) -- the bitnesses of the PEI and DXE
phases of the firmware.

IA32 stands for "32-bit PEI and DXE". Such firmware is usable for
booting 32-bit OSes only, and runs on both qemu-system-i386 and
qemu-system-x86_64.

IA32X64 stands for "32-bit PEI, 64-bit DXE". Needs qemu-system-x86_64
and runs 64-bit OSes only.

X64 stands for "64-bit PEI and DXE". Needs qemu-system-x86_64 and runs
64-bit OSes only.


(1) SECURE_BOOT_ENABLE (boolean) -- whether the Secure Boot UEFI feature
is built into the firmware image.

This decides whether the Secure Boot software interfaces will be
available to the guest OS. Turning on just this flag does not imply that
the guest OS cannot circumvent the SB software interfaces by direct
(guest kernel) access to the pflash chip.


(2) SMM_REQUIRE (boolean) -- whether the SMM driver stack is included in
the firmware.

If this flag is enabled, then SMM emulation is required from the board
(implying Q35), otherwise the firmware will not boot.

If enabled in combination with SECURE_BOOT_ENABLE, *and* the "secure"
property of the "cfi.pflash01" driver is set to "on", then the
circumvention under (1) is prevented by QEMU, and Secure Boot becomes
actually secure.

Regarding 32-bit x86 (qemu-system-i386), the compatible CPU models are
strongly limited; one model that works is "coreduo", but the NX flag has
to be disabled even on that.

If ARCH (from under (0)) is X64, and SMM_REQUIRE is enabled, then ACPI
S3 suspend/resume has to be disabled ("disable_s3" property of the
"ICH9-LPC" driver), otherwise the firmware will not boot. IA32 and
IA32X64 are not limited like this.


(3) HTTP_BOOT_ENABLE (boolean) -- whether UEFI HTTP boot is available in
the firmware image, in addition to the default PXE boot.


(4) TLS_ENABLE (boolean) -- configurable independently of
HTTP_BOOT_ENABLE, but only really makes sense in combination.

Determines whether HTTPS boot is available in the firmware image.


(5) NETWORK_IP6_ENABLE (boolean) -- determines whether IPv6 support is
available.

Orthogonal to all of: PXE, HTTP, HTTPS boot.


(6) FD_SIZE_IN_KB (one of: 1024, 2048, 4096) -- the size of the combined
firmware image (executable portion and variable store together), in KB.

(Boolean shorthands are FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB.)

Firmware images where this value is 1024 and 2048 are "compatible" with
each other in the sense that the variable store files they use are
identically structured. The variable store files are 128KB in size, and
the actual variable space they offer is 56KB. This is generally
sufficient for a low number of UEFI variables, and very basic key
enrollment for Secure Boot.

A firmware image where the value is 4096 is incompatible. The variable
store file is 528KB in size, and the actual variable space it offers is
256KB. This is considered "generous" by recent-ish industry practice,
and it is large enough for passing the Microsoft SVVP test cases related
to Secure Boot. (Obviously there are other requirements presented by
those test cases; I'm just saying that the size requirement is satisfied.)

The variable store template files are pre-formatted in all cases
(meaning "wire format" only -- on a logical level, they are "empty").
Under some circumstances, it could be desirable to provide varstore
template files that are pre-populated with various certificates
enrolled. It might make sense to describe such facts with another property.


(7) 

Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

2018-03-08 Thread Daniel P . Berrangé
On Thu, Mar 08, 2018 at 08:52:45AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > [*] Open question: Who, between QEMU and libvirt, should define the said
> > > firmware metadata format and file?
> > 
> > IMHO QEMU should be defining the format, because the file will contain
> > info about certain QEMU features associated with the firmware (eg smm).
> > Also there are potentially other non-libvirt mgmt apps that spawn QEMU
> > which would like this info (eg libguestfs), so having libvirt define the
> > format is inappropriate.
> > 
> > I'd suggest we just need something in docs/specs/firmware-metadata.rst
> > for QEMU source tree.
> > 
> > Potentially QEMU could even use the metadata files itself for finding
> > the default firmeware images, instead of compiling this info into its
> > binaries. I wouldn't suggest we need todo that right away, but bear it
> > in mind as a potential use case.
> 
> With qemu using this itself in mind it probably makes sense to specify
> this as qapi schema.  That'll simplify parsing and using these files in
> qemu, and possibly simplifies things on the libvirt side too.

I was thinking of an 'ini' style format, similar to that used by systemd
unit files, but a JSON format file is a nicer fit with QEMU & Libvirt if
we describe it with qapi.

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] [RFC] Defining firmware (OVMF, et al) metadata format & file

2018-03-08 Thread Daniel P . Berrangé
On Thu, Mar 08, 2018 at 08:45:07AM +0100, Gerd Hoffmann wrote:
> > Suggested approach
> > --
> > 
> > Based on an upstream discussion on 'virt-tools'[1] mailing list and some
> > Bugzillas, Gerd Hoffmann, Laszlo Ersek and Dan Berrangé had a suggestion
> > to define a firmware metadata format and file (example in [1]):
> > 
> >   - For each firmware file we need a metadata file in a well defined
> > location, e.g. /usr/share/qemu/bios/ that lists stuff like:
> > 
> >   - Path to the firmware binary
> >   - Path to the pre-built OVMF 'vars' file (if any)
> 
> How to load the binary (using -bios, -pflash, possibly also -kernel, for
> uboot @ arm).

I wonder if there's value in also using this for describing secondary
device specific ROMs like iPXE and friends.

> 
> >   - Support architectures - associated QEMU feature flags (Secure
> > Boot)
> 
> Also machine types.  ovmf builds with smm don't boot on pc.  coreboot
> has hardware-specific roms too, so the pc build wouldn't boot on q35 and
> visa versa.  Same on arm, where the firmware typically is board-specific.
> 
> >   - If the binary provides / requires SMM (System Management Mode)
> 
> Possibly a more generic "flags" or "properties" thing, I can easily
> imagine that simliar requirements show up on other platforms too.
> 
> Also a "name" and a "description" field would be useful.
> 
> cheers,
>   Gerd
> 

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 3/5] rpc: invoke the message dispatch callback with client unlocked

2018-03-08 Thread Daniel P . Berrangé
On Wed, Mar 07, 2018 at 06:48:25PM -0500, John Ferlan wrote:
> 
> 
> On 03/06/2018 12:58 PM, Daniel P. Berrangé wrote:
> > Currently if the virNetServer instance is created with max_workers==0 to
> > request a non-threaded dispatch process, we deadlock during dispatch
> > 
> >   #0  0x7fb845f6f42d in __lll_lock_wait () from /lib64/libpthread.so.0
> >   #1  0x7fb845f681d3 in pthread_mutex_lock () from 
> > /lib64/libpthread.so.0
> >   #2  0x55a6628bb305 in virMutexLock (m=) at 
> > util/virthread.c:89
> >   #3  0x55a6628a984b in virObjectLock (anyobj=) at 
> > util/virobject.c:435
> >   #4  0x55a66286fcde in virNetServerClientIsAuthenticated 
> > (client=client@entry=0x55a663a7b960)
> >   at rpc/virnetserverclient.c:1565
> >   #5  0x55a66286cc17 in virNetServerProgramDispatchCall 
> > (msg=0x55a663a7bc50, client=0x55a663a7b960,
> >   server=0x55a663a77550, prog=0x55a663a78020) at 
> > rpc/virnetserverprogram.c:407
> >   #6  virNetServerProgramDispatch (prog=prog@entry=0x55a663a78020, 
> > server=server@entry=0x55a663a77550,
> >   client=client@entry=0x55a663a7b960, msg=msg@entry=0x55a663a7bc50) at 
> > rpc/virnetserverprogram.c:307
> >   #7  0x55a662871d56 in virNetServerProcessMsg (msg=0x55a663a7bc50, 
> > prog=0x55a663a78020, client=0x55a663a7b960,
> >   srv=0x55a663a77550) at rpc/virnetserver.c:148
> >   #8  virNetServerDispatchNewMessage (client=0x55a663a7b960, 
> > msg=0x55a663a7bc50, opaque=0x55a663a77550)
> >   at rpc/virnetserver.c:227
> >   #9  0x55a66286e4c0 in virNetServerClientDispatchRead 
> > (client=client@entry=0x55a663a7b960)
> >   at rpc/virnetserverclient.c:1322
> >   #10 0x55a66286e813 in virNetServerClientDispatchEvent 
> > (sock=, events=1, opaque=0x55a663a7b960)
> >   at rpc/virnetserverclient.c:1507
> >   #11 0x55a662899be0 in virEventPollDispatchHandles 
> > (fds=0x55a663a7bdc0, nfds=)
> >   at util/vireventpoll.c:508
> >   #12 virEventPollRunOnce () at util/vireventpoll.c:657
> >   #13 0x55a6628982f1 in virEventRunDefaultImpl () at util/virevent.c:327
> >   #14 0x55a6628716d5 in virNetDaemonRun (dmn=0x55a663a771b0) at 
> > rpc/virnetdaemon.c:858
> >   #15 0x55a662864c1d in main (argc=, 
> > argv=0x7ffd105b4838) at logging/log_daemon.c:1235
> > 
> > Signed-off-by: Daniel P. Berrangé 
> > ---
> >  src/rpc/virnetserverclient.c | 79 
> > ++--
> >  1 file changed, 55 insertions(+), 24 deletions(-)
> > 
> 
> I had the same syntax-check notes that Jim had.
> 
> Beyond that since both callers Unlock prior to calling
> virNetServerClientDispatchMessage and the code relocks right away, would
> calling with client lock'd still be prudent/possible?  Callers would
> then be able to
> 
> if (msg)
> virNetServerClientDispatchMessage(...)
> else
> Unlock(client)
> 
> Once we get to virNetServerProgramDispatch it expects an unlocked
> client. Maybe we should comment some of the other callers in the path to
> indicate whether server/client need to be locked. Not required though -
> only helpful for future spelunkers of this code.

I generally like to avoid situations where one method locks the object and
then calls another method which unlocks it. IMHO, it leads to harder to
understand code where the lock/unlock calls are spread out.

Since we own the reference on client, I think unlocking & locking again
is harmless here.

> > @@ -1313,16 +1347,6 @@ static void 
> > virNetServerClientDispatchRead(virNetServerClientPtr client)
> >  }
> >  }
> >  
> > -/* Send off to for normal dispatch to workers */
> > -if (msg) {
> > -if (!client->dispatchFunc) {
> > -virNetMessageFree(msg);
> > -client->wantClose = true;
> > -} else {
> > -client->dispatchFunc(client, msg, client->dispatchOpaque);
> > -}
> > -}
> > -
> 
> I thought about the order change here w/r/t the following code being run
> before the dispatch options above; however, that would perhaps more of a
> concern for the path where we have no workers. If we have a worker, then
> it gets queued and the following would then occur first anyway, right?
> So, IOW, I think the reordering here is fine. It would happen before the
> worker got around to handling the client and moving it around to
> virNetServerClientDispatchMessage could get ugly w/r/t locks.

Yeah, that was my rationale too - since worker threads are asynchronous
we're effectively running the second block first regardless, so the
ordering should be harmless.

> 
> Reviewed-by: John Ferlan 
> 
> John
> 
> 
> >  /* Possibly need to create another receive buffer */
> >  if (client->nrequests < client->nrequests_max) {
> >  if (!(client->rx = virNetMessageNew(true))) {
> > @@ -1338,6 +1362,8 @@ static void 
> > 

Re: [libvirt] [PATCH 4/5] rpc: avoid crashing in pre-exec if no workers are present

2018-03-08 Thread Daniel P . Berrangé
On Wed, Mar 07, 2018 at 06:50:09PM -0500, John Ferlan wrote:
> 
> 
> On 03/06/2018 12:58 PM, Daniel P. Berrangé wrote:
> > If max_workers is set to zero, then the worker thread pool won't be
> > created, so when serializing state for pre-exec we must set various
> > parameters to zero.
> > 
> > Signed-off-by: Daniel P. Berrangé 
> > ---
> >  src/rpc/virnetserver.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> 
> Alternatively, the various virThreadPoolGet* API's could check :
> 
> if (!pool)
> return 0;
> 
> and we don't run into the same problem for other callers for all the API's.

My general opinion is that code should never knowingly pass NULL into
object methods, so I prefer to handle this in callers.

> 
> This works, but for this limited case of data being fetched.
> 
> It'd be a weak R-b at best.
> 
> John
> 
> > diff --git a/src/rpc/virnetserver.c b/src/rpc/virnetserver.c
> > index 7a1376bf49..3ce21a8f53 100644
> > --- a/src/rpc/virnetserver.c
> > +++ b/src/rpc/virnetserver.c
> > @@ -580,18 +580,21 @@ virJSONValuePtr 
> > virNetServerPreExecRestart(virNetServerPtr srv)
> >  goto error;
> >  
> >  if (virJSONValueObjectAppendNumberUint(object, "min_workers",
> > +   srv->workers == NULL ? 0 :
> > 
> > virThreadPoolGetMinWorkers(srv->workers)) < 0) {
> >  virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > _("Cannot set min_workers data in JSON document"));
> >  goto error;
> >  }
> >  if (virJSONValueObjectAppendNumberUint(object, "max_workers",
> > +   srv->workers == NULL ? 0 :
> > 
> > virThreadPoolGetMaxWorkers(srv->workers)) < 0) {
> >  virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > _("Cannot set max_workers data in JSON document"));
> >  goto error;
> >  }
> >  if (virJSONValueObjectAppendNumberUint(object, "priority_workers",
> > +   srv->workers == NULL ? 0 :
> > 
> > virThreadPoolGetPriorityWorkers(srv->workers)) < 0) {
> >  virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > _("Cannot set priority_workers data in JSON 
> > document"));
> > 

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] RFC regarding libvirtd deadlock

2018-03-08 Thread Daniel P . Berrangé
On Wed, Mar 07, 2018 at 04:52:26PM -0700, Jim Fehlig wrote:
> Doing something foolish like
> 
> # while true; do killall -HUP libvirtd; sleep 1; done
> # virsh create vm.xml
> 
> can deadlock libvirtd. Threads of interest are
> 
> Thread 4 (Thread 0x7fc13b53e700 (LWP 64084)):
> #0  0x7fc13fba10bf in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x7fc14310213c in virCondWait (c=0x7fc110017fa8, m=0x7fc110017f80)
> at util/virthread.c:154
> #2  0x7fc1280244e9 in qemuMonitorSend (mon=0x7fc110017f70, 
> msg=0x7fc13b53d240)
> at qemu/qemu_monitor.c:1083
> #3  0x7fc12803bf5a in qemuMonitorJSONCommandWithFd (mon=0x7fc110017f70,
> cmd=0x7fc110017700, scm_fd=-1, reply=0x7fc13b53d318) at
> qemu/qemu_monitor_json.c:305
> #4  0x7fc12803c09c in qemuMonitorJSONCommand (mon=0x7fc110017f70,
> cmd=0x7fc110017700,
> reply=0x7fc13b53d318) at qemu/qemu_monitor_json.c:335
> ---Type  to continue, or q  to quit---
> #5  0x7fc12803f116 in qemuMonitorJSONSetCapabilities (mon=0x7fc110017f70)
> at qemu/qemu_monitor_json.c:1298
> #6  0x7fc128026e14 in qemuMonitorSetCapabilities (mon=0x7fc110017f70)
> at qemu/qemu_monitor.c:1697
> #7  0x7fc127ffe250 in qemuProcessInitMonitor (driver=0x7fc12004e1e0,
> vm=0x7fc110003d00, asyncJob=QEMU_ASYNC_JOB_START) at 
> qemu/qemu_process.c:1763
> #8  0x7fc127ffe564 in qemuConnectMonitor (driver=0x7fc12004e1e0,
> vm=0x7fc110003d00,
> asyncJob=6, logCtxt=0x7fc1100089c0) at qemu/qemu_process.c:1835
> #9  0x7fc127fff386 in qemuProcessWaitForMonitor (driver=0x7fc12004e1e0,
> vm=0x7fc110003d00, asyncJob=6, logCtxt=0x7fc1100089c0) at
> qemu/qemu_process.c:2180
> #10 0x7fc128009269 in qemuProcessLaunch (conn=0x7fc119a0,
> driver=0x7fc12004e1e0,
> vm=0x7fc110003d00, asyncJob=QEMU_ASYNC_JOB_START, incoming=0x0, 
> snapshot=0x0,
> vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=17) at 
> qemu/qemu_process.c:6111
> #11 0x7fc128009e85 in qemuProcessStart (conn=0x7fc119a0,
> driver=0x7fc12004e1e0,
> vm=0x7fc110003d00, updatedCPU=0x0, asyncJob=QEMU_ASYNC_JOB_START,
> migrateFrom=0x0,
> migrateFd=-1, migratePath=0x0, snapshot=0x0,
> vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE,
> flags=17) at qemu/qemu_process.c:6334
> #12 0x7fc1280552f1 in qemuDomainCreateXML (conn=0x7fc119a0,
> xml=0x7fc11ed0 " 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] Libvirt and Vmware support

2018-03-08 Thread Egoitz Aurrekoetxea
Good morning,

I had the intention to integrate Libvirt with Xen, Vmware and KVM. We
are in process of migrating to KVM but needed to integrate for some time
VMware mainly. Does it support or are plans to, support Vmware
ESX/Vcenter 6.X?.

Best regards,
-- 


sarenet
*Egoitz Aurrekoetxea*
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
ego...@sarenet.es 
www.sarenet.es 

Antes de imprimir este correo electrónico piense si es necesario hacerlo.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] apparmor: add ro rule for sasl GSSAPI plugin on /etc/gss/mech.d/

2018-03-08 Thread Jamie Strandboge
On Wed, 2018-03-07 at 11:16 +0100, Christian Ehrhardt wrote:
> If a system has sasl GSSAPI plugin available qemu with sasl support
> will
> try to read /etc/gss/mech.d/.
> 
> It is required to allow that to let the modules fully work and it
> should
> be safe to do so as it only registers/configures plugins but has no
> secrets.
> 
> Signed-off-by: Christian Ehrhardt 
> ---
>  examples/apparmor/libvirt-qemu | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/examples/apparmor/libvirt-qemu
> b/examples/apparmor/libvirt-qemu
> index 950b042..2c47652 100644
> --- a/examples/apparmor/libvirt-qemu
> +++ b/examples/apparmor/libvirt-qemu
> @@ -192,3 +192,7 @@
># silence refusals to open lttng files (see LP: #1432644)
>deny /dev/shm/lttng-ust-wait-* r,
>deny /run/shm/lttng-ust-wait-* r,
> +
> +  # required for sasl GSSAPI plugin
> +  /etc/gss/mech.d/ r,
> +  /etc/gss/mech.d/* r,

LGTM. +1

Thanks!
-- 
Jamie Strandboge | http://www.canonical.com

signature.asc
Description: This is a digitally signed message part
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list