Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Alex Williamson]

On Wed, 21 Sep 2016 04:10:53 +
"Tian, Kevin"  wrote:

> > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > Sent: Wednesday, September 21, 2016 12:23 AM
> > 
> > 
> > On 9/20/2016 8:13 PM, Alex Williamson wrote:  
> > > On Tue, 20 Sep 2016 19:51:58 +0530
> > > Kirti Wankhede  wrote:
> > >  
> > >> On 9/20/2016 3:06 AM, Alex Williamson wrote:  
> > >>> On Tue, 20 Sep 2016 02:05:52 +0530
> > >>> Kirti Wankhede  wrote:
> > >>>  
> >  Hi libvirt experts,
> > 
> > 
> >  'create':
> >  Write-only file. Mandatory.
> >  Accepts string to create mediated device.
> > 
> >  'name':
> >  Read-Only file. Mandatory.
> >  Returns string, the name of that type id.
> > 
> >  'fb_length':
> >  Read-only file. Mandatory.
> >  Returns {K,M,G}, size of framebuffer.  
> > >>>
> > >>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> > >>> just one user of mediated devices.
> > >>>  
> > >>
> > >> As per our discussion in BOF, we would define class and its attributes.
> > >> As I mentioned above these are attributes of "display" class.  
> > >
> > > Just as I didn't know here, how does libvirt know the class of a given
> > > type id?
> > >  
> > 
> > Yes, we need some way to identify the class as Daniel mentioned in his
> > suggestion. Add a file 'class' in mdev_supported_types that would return
> > the class.
> > 
> >   
> 
> 'display' class or 'gpu' class? display represents only part of GPU 
> functionalities. I assume you want to provide an unique class ID
> for each type, instead of allowing multiple classes each identifying
> a subset of controllable GPU resources (e.g. 'display', 'render', etc.)...

Not sure where you're going with this, we're not creating a programming
interface for the device, that exists through the vfio API.  I believe
the intention here is simply a user level classification for the
purpose of being able to interpret the attributes provided in a logical
way.

> for unique class ID, I once considered whether it could be directly
> inherited from class of parent device, since typically a vendor driver
> creates mdev devices using the same type as physical device. But later
> I realized one potential value of keep a class field for mdev types,
> e.g. if we want to extend mdev to FPGA which could be programmed
> as different classes of functionalities. :-)

And how do we generically determine the class of a parent device?  We
cannot assume the parent device is PCI.  Thanks,

Alex

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Alex Williamson]

On Wed, 21 Sep 2016 03:56:21 +
"Tian, Kevin"  wrote:

> > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > Sent: Tuesday, September 20, 2016 10:22 PM  
> > >>
> > >> 'max_instance':
> > >> Read-Only file. Mandatory.
> > >> Returns integer.  Returns maximum mdev device could be created
> > >> at the moment when this file is read. This count would be updated by
> > >> vendor driver. Before creating mdev device of this type, check if
> > >> max_instance is > 0.  
> > >
> > > Didn't we discuss this being being something like "available_instances"
> > > with a "devices" sub-directory linking current devices of that type?
> > >  
> > 
> > I'm ok with 'available_instances' as name of this file.
> > Yes, mdev device directory will have links to devices of that type. I
> > think that is part of mdev core module discussion. I'm trying to list
> > sysfs files for libvirt interface here to focus more on libvirt
> > interface. Hence didn't add that. I'll make sure to add all such details
> > in future.
> > 
> >   
> 
> Definitely you need provide those details since they also contain
> libvirt interface, e.g. 'destroy' which we discussed should be in
> mdev directory.

$ find /sys/devices -name remove | wc -l
24
$ find /sys/devices -name destroy | wc -l
0

'remove' is the sysfs deconstructor we should use.

> Another example is class-specific attributes such
> as 'resolution', etc. which you listed under 'display class'. All those
> attributes should be moved to mdev directory. Only class ID is
> required under each type.

Can you elaborate on what you're proposing here?  If we don't have
attributes like 'resolution' under the type-id then we can't describe
to the user the features of the mdev before we create it.  I don't
think anybody wants a 'create it and find out' type of interface.
Thanks,

Alex

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Tian, Kevin]

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Wednesday, September 21, 2016 12:23 AM
> 
> 
> On 9/20/2016 8:13 PM, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 19:51:58 +0530
> > Kirti Wankhede  wrote:
> >
> >> On 9/20/2016 3:06 AM, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede  wrote:
> >>>
>  Hi libvirt experts,
> 
> 
>  'create':
>  Write-only file. Mandatory.
>  Accepts string to create mediated device.
> 
>  'name':
>  Read-Only file. Mandatory.
>  Returns string, the name of that type id.
> 
>  'fb_length':
>  Read-only file. Mandatory.
>  Returns {K,M,G}, size of framebuffer.
> >>>
> >>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> >>> just one user of mediated devices.
> >>>
> >>
> >> As per our discussion in BOF, we would define class and its attributes.
> >> As I mentioned above these are attributes of "display" class.
> >
> > Just as I didn't know here, how does libvirt know the class of a given
> > type id?
> >
> 
> Yes, we need some way to identify the class as Daniel mentioned in his
> suggestion. Add a file 'class' in mdev_supported_types that would return
> the class.
> 
> 

'display' class or 'gpu' class? display represents only part of GPU 
functionalities. I assume you want to provide an unique class ID
for each type, instead of allowing multiple classes each identifying
a subset of controllable GPU resources (e.g. 'display', 'render', etc.)...

for unique class ID, I once considered whether it could be directly
inherited from class of parent device, since typically a vendor driver
creates mdev devices using the same type as physical device. But later
I realized one potential value of keep a class field for mdev types,
e.g. if we want to extend mdev to FPGA which could be programmed
as different classes of functionalities. :-)

Thanks
Kevin

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Tian, Kevin]

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Tuesday, September 20, 2016 10:22 PM
> >>
> >> 'max_instance':
> >> Read-Only file. Mandatory.
> >> Returns integer.  Returns maximum mdev device could be created
> >> at the moment when this file is read. This count would be updated by
> >> vendor driver. Before creating mdev device of this type, check if
> >> max_instance is > 0.
> >
> > Didn't we discuss this being being something like "available_instances"
> > with a "devices" sub-directory linking current devices of that type?
> >
> 
> I'm ok with 'available_instances' as name of this file.
> Yes, mdev device directory will have links to devices of that type. I
> think that is part of mdev core module discussion. I'm trying to list
> sysfs files for libvirt interface here to focus more on libvirt
> interface. Hence didn't add that. I'll make sure to add all such details
> in future.
> 
> 

Definitely you need provide those details since they also contain
libvirt interface, e.g. 'destroy' which we discussed should be in
mdev directory. Another example is class-specific attributes such
as 'resolution', etc. which you listed under 'display class'. All those
attributes should be moved to mdev directory. Only class ID is
required under each type.

Thanks
Kevin

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

Re: [libvirt] [PATCH rfc v2 0/8] fspool: backend directory

[John Ferlan]

On 09/15/2016 03:32 AM, Olga Krishtal wrote:
> Hi everyone, we would like to propose the first implementation of fspool
> with directory backend.
> 
> Filesystem pools is a facility to manage filesystems resources similar
> to how storage pools manages volume resources. Furthermore new API follows
> storage API closely where it makes sense. Uploading/downloading operations
> are not defined yet as it is not obvious how to make it properly. I guess
> we can use some kind of tar to make a stream from a filesystem. Please share
> you thoughts on this particular issue.


So how do you differentiate between with the existing 

http://libvirt.org/storage.html#StorageBackendFS

Sure the existing fs pool requires/uses a source block device as the
source path and this new variant doesn't require that source but seems
to use some item in order to dictate how to "define" the source on the
fly. Currently only a "DIR" is created - so how does that differ from a
"dir" pool.

I think it'll be confusing to have and differentiate fspool and pool
commands.

I didn't dig through all the patches, but from the few I did look at it
seems as though all that's done is to rip out the guts of stuff not
desired from the storage pool driver and replace it with this new code
attributing all the work to the new author/copyright. IOW: Lots of
places where StoragePool appears to be exactly the same as the FSPool.

I think you need to find a different means to do what you want. It's not
100% what the end goal is.

I did download/git am the patches and scan a few patches...
  * In patch 2 you've totally missed how to modify libvirt_public.syms.
  * In patch 3, the build breaks in "conf/fs_conf" since the "if { if {}
}" aren't done properly in virFSPoolDefFormatBuf.
  * In patch 5 the remote_protocol_structs fails check/syntax-check... I
stopped there in my build each patch test.

John

> 
> The patchset provides 'dir' backend which simply expose directories in some
> directory in host filesystem. The virsh commands are provided too. So it is
> ready to play with, just replace 'pool' in xml descriptions and virsh commands
> to 'fspool' and 'volume' to 'item'.
> Examle and usage:
> Define:
> virsh -c qemu:///system fspool-define-as fs_pool_name dir --target 
> /path/on/host
> Build
> virsh -c qemu:///system fspool-build fs_pool_name
> Start
> virsh -c qemu:///system fspool-start fs_pool_name
> Look inside
> virsh -c qemu:///system fspool-list (--all) fspool_name
> 
> Fspool called POOL, on the host fs uses /fs_driver to hold items.
>   virsh -c qemu:///system fspool-dumpxml POOL
>   
> POOL
> c57c9d7c-b1d5-4c45-ba9c-67f03d4da160
> 733722615808
> 1331486720
> 534810800128
> 
> 
> 
>   /fs_driver
>   
> 0755
> 0
> 0
>   
> 
>   
> 
> virsh -c qemu:///system fspool-info POOL
> Name:   POOL
> UUID:   c57c9d7c-b1d5-4c45-ba9c-67f03d4da160
> State:  running
> Persistent: yes
> Autostart:  no autostart
> Capacity:   683.33 GiB
> Allocation: 1.24 GiB
> Available:  498.08 GiB
> 
> virsh -c qemu+unix:///system item-list POOL
>   Name Path
> --
> item1/fs_driver/item1
> item10   /fs_driver/item10
> item11   /fs_driver/item11
> item12   /fs_driver/item12
> item15   /fs_driver/item15
> 
> Fspool of directory type is some directory on host fs that holds items 
> (subdirs).
> Example of usage for items:
> virsh -c vz+unix:///system item-create-as POOL item1 1g - create item
> virsh -c qemu+unix:///system item-dumpxml item1 POOL
> 
> item1
> /fs_driver/item1
> 
> 
> 0
> 0
> 
>   
> 
>   
> 
> virsh -c qemu+unix:///system item-info item1 POOL
> Name:   item1
> Type:   dir
> Capacity:   683.33 GiB
> Allocation: 634.87 MiB
> Autostart:  no autostart
> Capacity:   683.33 GiB
> Allocation: 1.24 GiB
> Available:  498.08 GiB
> virsh -c qemu+unix:///system item-list POOL
>   Name Path
> --
>   item1/fs_driver/item1
>   item10   /fs_driver/item10
>   item11   /fs_driver/item11
>   item12   /fs_driver/item12
>   item15   /fs_driver/item15
> 
> v2:
> - renamed Fs to FS
> - in configure.ac script macro m4 is used
> - updates docs
> - created simple tests
> - updated virsh.pod
> - added information  abot fspool in fotmatfs.html
> 
> Olga Krishtal (8):
>   fspool: introduce filesystem pools API
>   fspool: usual driver based implementation of filesystem pools API
>   fspools: configuration and internal representation
>   fspools: acl support for filesystem pools
>   remote: filesystem pools driver implementation
>   fspool: default implementation of filesystem pools
>   

Re: [libvirt] [PATCH v1 3/4] xenconfig: channels conversion support

[Jim Fehlig]

Joao Martins wrote:
> On 09/20/2016 04:04 AM, Jim Fehlig wrote:
>> On 09/16/2016 05:43 PM, Joao Martins wrote:
>>> Add support for formating/parsing libxl channels.
>>>
>>> Syntax on xen libxl goes as following:
>>> channel=["connection=pty|socket,path=/path/to/socket,name=XXX",...]
>>>
>>> Signed-off-by: Joao Martins 
>>> ---
>>>  src/xenconfig/xen_xl.c | 176 
>>> +
>>>  1 file changed, 176 insertions(+)
>>>
>>> diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
>>> index 7774dfc..eea24b9 100644
>>> --- a/src/xenconfig/xen_xl.c
>>> +++ b/src/xenconfig/xen_xl.c
>>> @@ -685,6 +685,93 @@ xenParseXLUSB(virConfPtr conf, virDomainDefPtr def)
>>>  return 0;
>>>  }
>>>  
>>> +static int
>>> +xenParseXLChannel(virConfPtr conf, virDomainDefPtr def)
>>> +{
>>> +virConfValuePtr list = virConfGetValue(conf, "channel");
>>> +virDomainChrDefPtr channel = NULL;
>>> +char *name = NULL;
>>> +char *path = NULL;
>>> +
>>> +if (list && list->type == VIR_CONF_LIST) {
>>> +list = list->list;
>>> +while (list) {
>>> +char type[10];
>>> +char *key;
>>> +
>>> +if ((list->type != VIR_CONF_STRING) || (list->str == NULL))
>>> +goto skipchannel;
>>> +
>>> +key = list->str;
>>> +while (key) {
>>> +char *data;
>>> +char *nextkey = strchr(key, ',');
>>> +
>>> +if (!(data = strchr(key, '=')))
>>> +goto skipchannel;
>>> +data++;
>>> +
>>> +if (STRPREFIX(key, "connection=")) {
>>> +int len = nextkey ? (nextkey - data) : sizeof(type) - 
>>> 1;
>>> +if (virStrncpy(type, data, len, sizeof(type)) == NULL) 
>>> {
>>> +virReportError(VIR_ERR_INTERNAL_ERROR,
>>> +   _("connection %s too big"), data);
>>> +goto skipchannel;
>>> +}
>>> +} else if (STRPREFIX(key, "name=")) {
>>> +int len = nextkey ? (nextkey - data) : strlen(data);
>>> +VIR_FREE(name);
>>> +if (VIR_STRNDUP(name, data, len) < 0)
>>> +goto cleanup;
>>> +} else if (STRPREFIX(key, "path=")) {
>>> +int len = nextkey ? (nextkey - data) : strlen(data);
>>> +VIR_FREE(path);
>>> +if (VIR_STRNDUP(path, data, len) < 0)
>>> +goto cleanup;
>>> +}
>>> +
>>> +while (nextkey && (nextkey[0] == ',' ||
>>> +   nextkey[0] == ' ' ||
>>> +   nextkey[0] == '\t'))
>>> +nextkey++;
>>> +key = nextkey;
>>> +}
>>> +
>>> +if (!(channel = virDomainChrDefNew()))
>>> +goto cleanup;
>>> +
>>> +if (STRPREFIX(type, "socket")) {
>>> +channel->source.type = VIR_DOMAIN_CHR_TYPE_UNIX;
>>> +channel->source.data.nix.path = path;
>>> +channel->source.data.nix.listen = 1;
>>> +} else if (STRPREFIX(type, "pty")) {
>>> +channel->source.type = VIR_DOMAIN_CHR_TYPE_PTY;
>>> +VIR_FREE(path);
>>> +} else {
>>> +goto cleanup;
>>> +}
>>> +
>>> +channel->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL;
>>> +channel->targetType = VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN;
>>> +channel->target.name = name;
>>> +
>>> +if (VIR_APPEND_ELEMENT(def->channels, def->nchannels, channel) 
>>> < 0)
>>> +goto cleanup;
>>> +
>>> +skipchannel:
>>> +list = list->next;
>>> +}
>>> +}
>>> +
>>> +return 0;
>>> +
>>> + cleanup:
>>> +virDomainChrDefFree(channel);
>>> +VIR_FREE(path);
>>> +VIR_FREE(name);
>>> +return -1;
>>> +}
>>> +
>>>  virDomainDefPtr
>>>  xenParseXL(virConfPtr conf,
>>> virCapsPtr caps,
>>> @@ -720,6 +807,9 @@ xenParseXL(virConfPtr conf,
>>>  if (xenParseXLUSBController(conf, def) < 0)
>>>  goto cleanup;
>>>  
>>> +if (xenParseXLChannel(conf, def) < 0)
>>> +goto cleanup;
>>> +
>>>  if (virDomainDefPostParse(def, caps, VIR_DOMAIN_DEF_PARSE_ABI_UPDATE,
>>>xmlopt) < 0)
>>>  goto cleanup;
>>> @@ -1347,6 +1437,89 @@ xenFormatXLUSB(virConfPtr conf,
>>>  return -1;
>>>  }
>>>  
>>> +static int
>>> +xenFormatXLChannel(virConfValuePtr list, virDomainChrDefPtr channel)
>>> +{
>>> +virBuffer buf = VIR_BUFFER_INITIALIZER;
>>> +int sourceType = channel->source.type;
>>> +virConfValuePtr val, tmp;
>>> +
>>> +/* connection */
>>> +virBufferAddLit(, "connection=");
>>> +switch (sourceType) {

Re: [libvirt] [PATCH v2] storage: vz storage pool support

[John Ferlan]

On 07/14/2016 01:13 PM, Olga Krishtal wrote:
> This patch supports pool and volume management within Virtuozzo Storage.
> Virtuozzo Storage is a highly-available distributed software defined storage
> with built-in replication and disaster recovery. From client's point of
> view it looks like network attached storage (NFS or GlusterFS).
> More information about vzstorage can be found here: 
> https://openvz.org/Virtuozzo_Storage
> It supports the same volume formats as directory, nfs, etc.
> Default format is raw.
> 
> Signed-off-by: Olga Krishtal 
> ---
>  configure.ac  |  31 +++
>  docs/schemas/storagepool.rng  |  29 ++
>  include/libvirt/libvirt-storage.h |   1 +
>  src/conf/storage_conf.c   |  16 +-
>  src/conf/storage_conf.h   |   4 +-
>  src/storage/storage_backend.c |   3 +
>  src/storage/storage_backend_fs.c  | 112 
> +-
>  src/storage/storage_backend_fs.h  |   3 +
>  src/storage/storage_driver.c  |   2 +
>  tools/virsh-pool.c|   2 +
>  tools/virsh.c |   3 +
>  11 files changed, 203 insertions(+), 3 deletions(-)
> 

In an effort to go through older on list bugs I'm wondering about the
relative importance of this compared to the fspool series.  Shall I
assume this is dropped in favor of that?

Tks -

John

FWIW: It compiled, but failed syntax-check.  Also the name "vstorage"
would seemingly be a bit too generic. I saw and thought virtual storage
not Virtuozzo Storage


> diff --git a/configure.ac b/configure.ac
> index 2c81c95..2ee8b8c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1692,6 +1692,10 @@ AC_ARG_WITH([storage-zfs],
>[AS_HELP_STRING([--with-storage-zfs],
>  [with ZFS backend for the storage driver @<:@default=check@:>@])],
>[],[with_storage_zfs=check])
> +AC_ARG_WITH([storage-vstorage],
> +  [AS_HELP_STRING([--with-storage-vstorage],
> +[with VZ backend for the storage driver @<:@default=check@:>@])],
> +  [],[with_storage_vstorage=check])
>  
>  if test "$with_libvirtd" = "no"; then
>with_storage_dir=no
> @@ -1705,6 +1709,7 @@ if test "$with_libvirtd" = "no"; then
>with_storage_sheepdog=no
>with_storage_gluster=no
>with_storage_zfs=no
> +  with_storage_vstorage=no
>  fi
>  if test "$with_storage_dir" = "yes" ; then
>AC_DEFINE_UNQUOTED([WITH_STORAGE_DIR], 1, [whether directory backend for 
> storage driver is enabled])
> @@ -1963,6 +1968,31 @@ if test "$with_storage_fs" = "yes" ||
>fi
>  fi
>  
> +if test "$with_storage_vstorage" = "yes" || test "$with_storage_vstorage" = 
> "check"; then
> +   AC_PATH_PROG([VSTORAGE], [vstorage], [], [$PATH:/sbin:/usr/bin])
> +   AC_PATH_PROG([VSTORAGE_MOUNT], [vstorage-mount], [], 
> [$PATH:/sbin/usr/bin])
> +  if test "$with_storage_vstorage" = "yes"; then
> +if test -z "$VSTORAGE" ; then AC_MSG_ERROR([We need vstorage tools for 
> virtuozzo storage driver]); fi
> +if test -z "$VSTORAGE_MOUNT" ; then AC_MSG_ERROR([We need vstorage mount 
> tool for virtuozzo storage driver]); fi
> +if test  "$with_storage_fs" = "no"; then AC_MSG_ERROR([We need fs 
> backend for vstorage pool]); fi
> +  else
> +if test -z "$VSTORAGE" ; then with_storage_vstorage=no; fi
> +if test -z "$VSTORAGE" ; then with_storage_vstorage=no; fi
> +if test  "$with_storage_fs"= "no"; then with_storage_vstorage=no; fi
> +
> +if test "$with_storage_vstorage" = "check" ; then 
> with_storage_vstorage=yes ; fi
> +  fi
> +  if test "$with_storage_vstorage" = "yes"; then
> +  AC_DEFINE_UNQUOTED([WITH_STORAGE_VSTORAGE], 1, [whether virtuozzo 
> storage backend for storage driver is enabled])
> +  AC_DEFINE_UNQUOTED([VSTORAGE], ["$VSTORAGE"], [Location or name of 
> vstorage program])
> +  AC_DEFINE_UNQUOTED([VSTORAGE_MOUNT], ["$VSTORAGE_MOUNT"], [Location or 
> name of vstorage-mount program])
> +  AC_DEFINE_UNQUOTED([with_storage_fs], ["$VSTORAGE_MOUNT"], [must be 
> on])
> +  fi
> +
> +  if test "$with_storage_vstorage" = "check" ; then 
> with_storage_vstorage=yes ; fi
> +fi
> +AM_CONDITIONAL([WITH_STORAGE_VSTORAGE], [test "$with_storage_vstorage" = 
> "yes"])
> +
>  LIBPARTED_CFLAGS=
>  LIBPARTED_LIBS=
>  if test "$with_storage_disk" = "yes" ||
> @@ -2759,6 +2789,7 @@ AC_MSG_NOTICE([ RBD: $with_storage_rbd])
>  AC_MSG_NOTICE([Sheepdog: $with_storage_sheepdog])
>  AC_MSG_NOTICE([ Gluster: $with_storage_gluster])
>  AC_MSG_NOTICE([ ZFS: $with_storage_zfs])
> +AC_MSG_NOTICE([Vstorage: $with_storage_vstorage])
>  AC_MSG_NOTICE([])
>  AC_MSG_NOTICE([Security Drivers])
>  AC_MSG_NOTICE([])
> diff --git a/docs/schemas/storagepool.rng b/docs/schemas/storagepool.rng
> index 49d212f..8ad5616 100644
> --- a/docs/schemas/storagepool.rng
> +++ b/docs/schemas/storagepool.rng
> @@ -24,6 +24,7 @@
>  
>  
>  
> +
>
>  
>
> @@ -173,6 +174,18 @@
>  
>
>  
> +  
> + 
> +  vz
> +

Re: [libvirt] [PATCH v1 1/4] conf: add xen type for channels

[Jim Fehlig]

Joao Martins wrote:
> On 09/19/2016 11:29 PM, Jim Fehlig wrote:
>> On 09/16/2016 05:43 PM, Joao Martins wrote:
>>> So far only guestfwd and virtio were supported. Add an additional
>>> for Xen as libxl channels create Xen console visible to the guest.
>>>
>>> Signed-off-by: Joao Martins 
>>> ---
>>>  docs/schemas/domaincommon.rng | 11 +++
>>>  src/conf/domain_conf.c| 18 ++
>>>  src/conf/domain_conf.h|  1 +
>>>  src/qemu/qemu_command.c   |  1 +
>>>  4 files changed, 27 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
>>> index 8aaa67e..5901452 100644
>>> --- a/docs/schemas/domaincommon.rng
>>> +++ b/docs/schemas/domaincommon.rng
>>> @@ -3686,6 +3686,16 @@
>>>
>>>  
>>>
>>> +  
>>> +
>>> +  
>>> +xen
>>> +  
>>> +  
>>> +
>>> +  
>>> +
>>> +  
>>>
>>>  
>>>
>>> @@ -3694,6 +3704,7 @@
>>>  
>>>
>>>
>>> +  
>>>  
>>>  
>>>
>>> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>>> index 0828041..196799d 100644
>>> --- a/src/conf/domain_conf.c
>>> +++ b/src/conf/domain_conf.c
>>> @@ -434,7 +434,8 @@ VIR_ENUM_IMPL(virDomainChrChannelTarget,
>>>VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_LAST,
>>>"none",
>>>"guestfwd",
>>> -  "virtio")
>>> +  "virtio",
>>> +  "xen")
>>>  
>>>  VIR_ENUM_IMPL(virDomainChrConsoleTarget,
>>>VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST,
>>> @@ -2068,6 +2069,7 @@ void virDomainChrDefFree(virDomainChrDefPtr def)
>>>  VIR_FREE(def->target.addr);
>>>  break;
>>>  
>>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>>>  case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO:
>>>  VIR_FREE(def->target.name);
>>>  break;
>>> @@ -9877,10 +9879,12 @@ virDomainChrDefParseTargetXML(virDomainChrDefPtr 
>>> def,
>>>  virSocketAddrSetPort(def->target.addr, port);
>>>  break;
>>>  
>>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>>>  case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO:
>>>  def->target.name = virXMLPropString(cur, "name");
>>>  
>>> -if (!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) &&
>>> +if (def->targetType == 
>>> VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO &&
>>> +!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) &&
>>>  (stateStr = virXMLPropString(cur, "state"))) {
>>>  int tmp;
>> I guess we'll need an answer to your question about the 'state' attribute to
>> know if this is needed.
> Based in the earlier discussion with Michal I guess this can stay as it is?

Yep. Agreed that we wont support the 'state' attribute in the libxl driver at
this time.

Regards,
Jim

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

[libvirt] [PATCH v3 18/18] [RFC] qemu: try to put ich9 sound device at 00:1B.0

[Laine Stump]

Real Q35 hardware has an ICH9 chip that includes several integrated
devices at particular addresses (see the file docs/q35-chipset.cfg in
the qemu source). libvirt already attempts to put the first two sets
of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the
real hardware. This patch does the same for the ich9 "HD audio"
device.

The reason I made this patch is that currently the *only* device in a
reasonable "workstation" type virtual machine config that requires a
legacy PCI slot is the audio device, Without this patch, the standard
Q35 machine created by virt-manager will have a dmi-to-pci-bridge and
a pci-bridge just for the sound device; with the patch (and if you
change the sound device model from the default "ich6" to "ich9"), the
machine definition constructed by virt-manager has absolutely no
legacy PCI controllers - any legacy PCI devices (e.g. video and sound)
are on pcie-root as integrated devices.

As cool as it is to have virt-manager making a legacy-PCI-free config
so easily, I'm undecided whether or not this is a worthwhile patch. On
one hand, it's following an existing convention of trying to place
devices that are known to be integrated chipset devices on Q35
hardware at the same address they appear in real life (but doesn't
insist on this address, and doesn't add any new device if one isn't
already present in the config). On the other hand it creates yet
another exception to "follow the same formula for everything", while
it's probably better for us to be trying to *get away* from that.

Two alternate solutions:

1) convince virt-manager to use "ich9" as the default sound for Q35,
   and explicitly place it at 00:1B.0 in the definition it sends to
   libvirt.

2) convince qemu to add a PCI Express sound device (I'm not sure which
   one would be most appropriate).
---
 src/qemu/qemu_domain_address.c |  25 +
 .../qemuxml2argv-q35-virt-manager-basic.args   |  56 ++
 .../qemuxml2argv-q35-virt-manager-basic.xml|  76 ++
 tests/qemuxml2argvtest.c   |  31 ++
 .../qemuxml2xmlout-q35-virt-manager-basic.xml  | 116 +
 tests/qemuxml2xmltest.c|  23 
 6 files changed, 327 insertions(+)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.xml
 create mode 100644 
tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virt-manager-basic.xml

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index a9c4c32..6cfd710 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1218,6 +1218,31 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def,
 goto cleanup;
 }
 }
+
+memset(_addr, 0, sizeof(tmp_addr));
+tmp_addr.slot = 0x1B;
+if (!virDomainPCIAddressSlotInUse(addrs, _addr)) {
+/* Since real Q35 hardware has an ICH9 chip that has an
+ * integrated HD audio device at :00:1B.0 put any
+ * unaddressed ICH9 audio device at that address if it's not
+ * already taken. If there's something already there, let the
+ * normal device addressing assign something later.
+ */
+for (i = 0; i < def->nsounds; i++) {
+virDomainSoundDefPtr sound = def->sounds[i];
+
+if (sound->model != VIR_DOMAIN_SOUND_MODEL_ICH9)
+continue;
+if (!virDeviceInfoPCIAddressWanted(>info))
+break;
+if (virDomainPCIAddressReserveSlot(addrs, _addr, flags) < 0)
+goto cleanup;
+sound->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
+sound->info.addr.pci = tmp_addr;
+break;
+}
+}
+
 ret = 0;
  cleanup:
 VIR_FREE(addrStr);
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args
new file mode 100644
index 000..163e7f1
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args
@@ -0,0 +1,56 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=spice \
+/usr/bin/qemu-system_x86_64 \
+-name virt-manager-basic \
+-S \
+-M pc-q35-2.7 \
+-m 4096 \
+-smp 2,sockets=2,cores=1,threads=1 \
+-uuid 1b826c23-8767-47ad-a6b5-c83a88277f71 \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-virt-manager-basic/monitor.sock,server,nowait 
\
+-rtc base=utc,driftfix=slew \
+-no-kvm-pit-reinjection \
+-global ICH9-LPC.disable_s3=1 \
+-global ICH9-LPC.disable_s4=1 \
+-boot c \
+-device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,addr=0x2 \
+-device ioh3420,port=0x18,chassis=2,id=pci.2,bus=pcie.0,addr=0x3 \
+-device ioh3420,port=0x20,chassis=3,id=pci.3,bus=pcie.0,addr=0x4 \
+-device ioh3420,port=0x28,chassis=4,id=pci.4,bus=pcie.0,addr=0x5 \
+-device 

[libvirt] [PATCH v3 15/18] qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed

[Laine Stump]

Previously libvirt would only add pci-bridge devices automatically
when an address was requested for a device that required a legacy PCI
slot and none was available. This patch expands that support to
dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a
machine with a pcie-root), and pcie-root-port (which is needed to add
a hotpluggable PCIe device). It does *not* automatically add
pcie-switch-upstream-ports or pcie-switch-downstream-ports (and
currently there are no plans for that).

Given the existing code to auto-add pci-bridge devices, automatically
adding pcie-root-ports is fairly straightforward. The
dmi-to-pci-bridge support is a bit tricky though, for a few reasons:

1) Although the only reason to add a dmi-to-pci-bridge is so that
   there is a reasonable place to plug in a pci-bridge controller,
   most of the time it's not the presence of a pci-bridge *in the
   config* that triggers the requirement to add a dmi-to-pci-bridge.
   Rather, it is the presence of a legacy-PCI device in the config,
   which triggers auto-add of a pci-bridge, which triggers auto-add of
   a dmi-to-pci-bridge (this is handled in
   virDomainPCIAddressSetGrow() - if there's a request to add a
   pci-bridge we'll check if there is a suitable bus to plug it into;
   if not, we first add a dmi-to-pci-bridge).

2) Once there is already a single dmi-to-pci-bridge on the system,
   there won't be a need for any more, even if it's full, as long as
   there is a pci-bridge with an open slot - you can also plug
   pci-bridges into existing pci-bridges. So we have to make sure we
   don't add a dmi-to-pci-bridge unless there aren't any
   dmi-to-pci-bridges *or* any pci-bridges.

3) Although it is strongly discouraged, it is legal for a pci-bridge
   to be directly plugged into pcie-root, and we don't want to
   auto-add a dmi-to-pci-bridge if there is already a pci-bridge
   that's been forced directly into pcie-root. Finally, although I
   fail to see the utility of it, it is legal to have something like
   this in the xml:

 
 

   and that will lead to an automatically added dmi-to-pci-bridge at
   index=1 (to give the unaddressed pci-bridge a proper place to plug
   in):

 

   (for example, see the existing test case
   "usb-controller-default-q35"). This is handled in
   qemuDomainPCIAddressSetCreate() when it's adding in controllers to
   fill holes in the indexes.

Although libvirt will now automatically create a dmi-to-pci-bridge
when it's needed, the code still remains for now that forces a
dmi-to-pci-bridge on all domains with pcie-root (in
qemuDomainDefAddDefaultDevices()). That will be removed in the next
patch.

For now, the pcie-root-ports are added one to a slot, which is a bit
wasteful and means it will fail after 31 total PCIe devices (30 if
there are also some PCI devices), but helps keep the changeset down
for this patch. A future patch will have 8 pcie-root-ports sharing the
functions on a single slot.
---
 src/conf/domain_addr.c |  88 ++--
 src/qemu/qemu_domain_address.c |  91 ++---
 .../qemuxml2argv-q35-pcie-autoadd.args |  57 
 .../qemuxml2argv-q35-pcie-autoadd.xml  |  51 +++
 tests/qemuxml2argvtest.c   |  23 
 .../qemuxml2xmlout-q35-pcie-autoadd.xml| 147 +
 tests/qemuxml2xmltest.c|  23 
 7 files changed, 448 insertions(+), 32 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.xml
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie-autoadd.xml

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 12b5cb2..5f6f6f7 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -82,6 +82,30 @@ 
virDomainPCIControllerModelToConnectType(virDomainControllerModelPCI model)
 return 0;
 }
 
+
+static int
+virDomainPCIControllerConnectTypeToModel(virDomainPCIConnectFlags flags)
+{
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT;
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_UPSTREAM_PORT)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT;
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_DOWNSTREAM_PORT)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT;
+if (flags & VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE)
+return VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE;
+if (flags & VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS;
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_EXPANDER_BUS)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS;
+if (flags & VIR_PCI_CONNECT_TYPE_PCI_BRIDGE)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE;
+
+/* some connect types 

[libvirt] [PATCH v3 09/18] qemu: set/use info->pciConnectFlags during qemuDomainAssignDevicePCISlots

[Laine Stump]

Set pciConnectFlags in each device's DeviceInfo prior to assigning PCI
addresses, and then use those flags later when actually assigning the
addresses with qemuDomainPCIAddressReserveNextAddr() (rather than
scattering the logic about which devices need which type of slot all
over the place).
---
 src/qemu/qemu_domain_address.c | 234 ++---
 1 file changed, 104 insertions(+), 130 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 7de081b..ed728f5 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -555,7 +555,7 @@ qemuDomainDeviceConnectFlagsInternal(virDomainDeviceDefPtr 
dev,
  *  There is no failure, so there is no return value.
  *
  */
-static void ATTRIBUTE_UNUSED
+static void
 qemuDomainDeviceConnectFlags(virDomainDefPtr def,
  virDomainDeviceDefPtr dev,
  virQEMUCapsPtr qemuCaps)
@@ -636,7 +636,7 @@ qemuDomainDeviceConnectFlagsIterator(virDomainDefPtr def 
ATTRIBUTE_UNUSED,
  * 0 on success or -1 on failure (the only possibility of failure would
  * be some internal problem with virDomainDeviceInfoIterate())
  */
-static int ATTRIBUTE_UNUSED
+static int
 qemuDomainDeviceSetAllConnectFlags(virDomainDefPtr def,
virQEMUCapsPtr qemuCaps)
 {
@@ -658,21 +658,20 @@ qemuDomainDeviceSetAllConnectFlags(virDomainDefPtr def,
 static int
 qemuDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
 virDomainDeviceInfoPtr dev,
-virDomainPCIConnectFlags flags,
 unsigned int function,
 bool reserveEntireSlot)
 {
-return virDomainPCIAddressReserveNextAddr(addrs, dev, flags,
+return virDomainPCIAddressReserveNextAddr(addrs, dev,
+  dev->pciConnectFlags,
   function, reserveEntireSlot);
 }
 
 
 static int
 qemuDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
-virDomainDeviceInfoPtr dev,
-virDomainPCIConnectFlags flags)
+virDomainDeviceInfoPtr dev)
 {
-return qemuDomainPCIAddressReserveNextAddr(addrs, dev, flags, 0, true);
+return qemuDomainPCIAddressReserveNextAddr(addrs, dev, 0, true);
 }
 
 
@@ -686,9 +685,6 @@ qemuDomainCollectPCIAddress(virDomainDefPtr def 
ATTRIBUTE_UNUSED,
 int ret = -1;
 virPCIDeviceAddressPtr addr = >addr.pci;
 bool entireSlot;
-/* flags may be changed from default below */
-virDomainPCIConnectFlags flags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-  VIR_PCI_CONNECT_TYPE_PCI_DEVICE);
 
 if (!virDeviceInfoPCIAddressPresent(info) ||
 ((device->type == VIR_DOMAIN_DEVICE_HOSTDEV) &&
@@ -700,69 +696,25 @@ qemuDomainCollectPCIAddress(virDomainDefPtr def 
ATTRIBUTE_UNUSED,
 return 0;
 }
 
-/* Change flags according to differing requirements of different
- * devices.
+/* If we get to here, the device has a PCI address assigned in the
+ * config and we should mark it as in-use. But if the
+ * pciConnectFlags are 0, then this device shouldn't have a PCI
+ * address associated with it. *BUT* since there are cases in the
+ * past where we've apparently allowed that, we need to pretend
+ * for now that it's okay, otherwise an existing domain could
+ * "disappear" from the list of domains due to a parse failure. We
+ * can fix this by just forcing the pciConnectFlags to be
+ * PCI_DEVICE (and then relying on validation functions to report
+ * inappropriate address types.
  */
-switch (device->type) {
-case VIR_DOMAIN_DEVICE_CONTROLLER:
-switch (device->data.controller->type) {
-case  VIR_DOMAIN_CONTROLLER_TYPE_PCI:
-   flags = 
virDomainPCIControllerModelToConnectType(device->data.controller->model);
-break;
-
-case VIR_DOMAIN_CONTROLLER_TYPE_SATA:
-/* SATA controllers aren't hot-plugged, and can be put in
- * either a PCI or PCIe slot
- */
-flags = (VIR_PCI_CONNECT_TYPE_PCI_DEVICE
- | VIR_PCI_CONNECT_TYPE_PCIE_DEVICE);
-break;
-
-case VIR_DOMAIN_CONTROLLER_TYPE_USB:
-/* allow UHCI and EHCI controllers to be manually placed on
- * the PCIe bus (but don't put them there automatically)
- */
-switch (device->data.controller->model) {
-case VIR_DOMAIN_CONTROLLER_MODEL_USB_EHCI:
-case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_EHCI1:
-case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_UHCI1:
-case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_UHCI2:
-case 

[libvirt] [PATCH v3 17/18] qemu: add a USB3 controller to Q35 domains by default

[Laine Stump]

Previously we added a set of EHCI+UHCI controllers to Q35 machines to
mimic real hardware as closely as possible, but recent discussions
have pointed out that the nec-usb-xhci (USB3) controller is much more
virtualization-friendly (uses less CPU), so this patch switches the
default for Q35 machinetypes to add an XHCI instead (if it's
supported, which it of course *will* be).

Since none of the existing test cases left out USB controllers in the
input XML, a new Q35 test case was added which has *no* devices, so
ends up with only the defaults always put in by qemu, plus those added
by libvirt.
---
 src/qemu/qemu_domain.c | 10 --
 .../qemuxml2argv-q35-default-devices-only.args | 22 
 .../qemuxml2argv-q35-default-devices-only.xml  | 18 ++
 tests/qemuxml2argvtest.c   | 22 
 .../qemuxml2xmlout-q35-default-devices-only.xml| 40 ++
 tests/qemuxml2xmltest.c| 22 
 6 files changed, 131 insertions(+), 3 deletions(-)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml
 create mode 100644 
tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-default-devices-only.xml

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index eed8cfe..e1060ba 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1976,10 +1976,14 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def,
 addPCIeRoot = true;
 addImplicitSATA = true;
 
-/* add a USB2 controller set, but only if the
- * ich9-usb-ehci1 device is supported
+/* Prefer adding USB3 controller if supported
+ * (nec-usb-xhci). Failing that, add a USB2 controller set
+ * if the ich9-usb-ehci1 device is supported. Otherwise
+ * don't add anything.
  */
-if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ICH9_USB_EHCI1))
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
+usbModel = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
+else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ICH9_USB_EHCI1))
 usbModel = VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_EHCI1;
 else
 addDefaultUSB = false;
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args
new file mode 100644
index 000..9ac30dd
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args
@@ -0,0 +1,22 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name q35-test \
+-S \
+-M q35 \
+-m 2048 \
+-smp 2,sockets=2,cores=1,threads=1 \
+-uuid 11dbdcdd-4c3b-482b-8903-9bdb8c0a2774 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-q35-test/monitor.sock,server,nowait \
+-no-acpi \
+-boot c \
+-device ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,addr=0x1 \
+-device ioh3420,port=0x10,chassis=2,id=pci.2,bus=pcie.0,addr=0x2 \
+-device nec-usb-xhci,id=usb,bus=pci.1,addr=0x0 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml
new file mode 100644
index 000..7436583
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml
@@ -0,0 +1,18 @@
+
+  q35-test
+  11dbdcdd-4c3b-482b-8903-9bdb8c0a2774
+  2097152
+  2097152
+  2
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/libexec/qemu-kvm
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index cfa522c..db63b21 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1762,6 +1762,28 @@ mymain(void)
 QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_ICH9_USB_EHCI1,
 QEMU_CAPS_NEC_USB_XHCI,
 QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
+DO_TEST("q35-default-devices-only",
+QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
+QEMU_CAPS_DEVICE_VIRTIO_RNG,
+QEMU_CAPS_OBJECT_RNG_RANDOM,
+QEMU_CAPS_NETDEV,
+QEMU_CAPS_DEVICE_VIRTIO_NET,
+QEMU_CAPS_DEVICE_VIRTIO_GPU,
+QEMU_CAPS_DEVICE_VIRTIO_GPU_VIRGL,
+QEMU_CAPS_VIRTIO_KEYBOARD,
+QEMU_CAPS_VIRTIO_MOUSE,
+QEMU_CAPS_VIRTIO_TABLET,
+QEMU_CAPS_VIRTIO_INPUT_HOST,
+QEMU_CAPS_VIRTIO_SCSI,
+QEMU_CAPS_FSDEV,
+QEMU_CAPS_FSDEV_WRITEOUT,
+QEMU_CAPS_DEVICE_PCI_BRIDGE,
+QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
+QEMU_CAPS_DEVICE_IOH3420,
+QEMU_CAPS_ICH9_AHCI,
+QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_ICH9_USB_EHCI1,
+

[libvirt] [PATCH v3 13/18] qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate

[Laine Stump]

The nec-usb-xhci device (which is a USB3 controller) has always
presented itself as a PCI device when plugged into a legacy PCI slot,
and a PCIe device when plugged into a PCIe slot, but libvirt has
always auto-assigned it to a PCI slot.

This patch changes that behavior to auto-assign to a PCIe slot on
systems that have pcie-root (e.g. Q35 and aarch64/virt).

Since we don't yet auto-create pcie-*-port controllers on demand, this
means a config with an nec-xhci USB controller that has no PCI address
assigned will also need to have an otherwise-unused pcie-*-port
controller specified:

   
   

(this assumes there is an otherwise-unused slot on pcie-root to accept
the pcie-root-port)
---
 src/qemu/qemu_domain_address.c |  3 ++
 tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 10 +++
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args  | 21 ++---
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml   |  2 ++
 .../qemuxml2argv-q35-virtio-pci.args   |  7 ++---
 tests/qemuxml2argvtest.c   |  2 ++
 .../qemuxml2xmlout-autoindex.xml   | 10 +++
 .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 35 +-
 .../qemuxml2xmlout-q35-virtio-pci.xml  | 21 +
 9 files changed, 49 insertions(+), 62 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index e11a23b..83e3861 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -442,6 +442,9 @@ qemuDomainDeviceConnectFlagsInternal(virDomainDeviceDefPtr 
dev,
  cont->model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI) ||
 cont->type == VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL) {
 flags = virtioFlags;
+} else if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
+   cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI) {
+flags = pcieFlags;
 } else if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_FDC ||
cont->type == VIR_DOMAIN_CONTROLLER_TYPE_CCID ||
(cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args 
b/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args
index 43b9661..fc14dc4 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args
@@ -43,11 +43,11 @@ addr=0x1 \
 -device ich9-usb-uhci2,masterbus=usb2.0,firstport=2,bus=pci.2,addr=0x1.0x1 \
 -device ich9-usb-uhci3,masterbus=usb2.0,firstport=4,bus=pci.2,addr=0x1.0x2 \
 -device ich9-usb-ehci1,id=usb2,bus=pci.2,addr=0x1.0x7 \
--device nec-usb-xhci,id=usb3,bus=pci.2,addr=0x2 \
+-device nec-usb-xhci,id=usb3,bus=pci.5,addr=0x0 \
 -device 
ich9-usb-uhci1,masterbus=usb4.0,firstport=0,bus=pci.2,multifunction=on,\
-addr=0x3 \
--device ich9-usb-uhci2,masterbus=usb4.0,firstport=2,bus=pci.2,addr=0x3.0x1 \
--device ich9-usb-uhci3,masterbus=usb4.0,firstport=4,bus=pci.2,addr=0x3.0x2 \
--device ich9-usb-ehci1,id=usb4,bus=pci.2,addr=0x3.0x7 \
+addr=0x2 \
+-device ich9-usb-uhci2,masterbus=usb4.0,firstport=2,bus=pci.2,addr=0x2.0x1 \
+-device ich9-usb-uhci3,masterbus=usb4.0,firstport=4,bus=pci.2,addr=0x2.0x2 \
+-device ich9-usb-ehci1,id=usb4,bus=pci.2,addr=0x2.0x7 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-sata0-0-0 \
 -device ide-drive,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
index 40c8063..059b232 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
@@ -30,15 +30,12 @@ QEMU_AUDIO_DRV=none \
 -device ioh3420,port=0x58,chassis=12,id=pci.12,bus=pcie.0,addr=0xb \
 -device ioh3420,port=0x60,chassis=13,id=pci.13,bus=pcie.0,addr=0xc \
 -device ioh3420,port=0x68,chassis=14,id=pci.14,bus=pcie.0,addr=0xd \
--device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \
--device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,\
-addr=0x1d \
--device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \
--device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \
+-device ioh3420,port=0x70,chassis=15,id=pci.15,bus=pcie.0,addr=0xe \
+-device nec-usb-xhci,id=usb,bus=pci.8,addr=0x0 \
 -device virtio-scsi-pci,id=scsi0,bus=pci.7,addr=0x0 \
 -device virtio-serial-pci,id=virtio-serial0,bus=pci.6,addr=0x0 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk1 \
--device virtio-blk-pci,bus=pci.8,addr=0x0,drive=drive-virtio-disk1,\
+-device virtio-blk-pci,bus=pci.9,addr=0x0,drive=drive-virtio-disk1,\
 id=virtio-disk1 \
 -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/export/to/guest \
 -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=/import/from/host,\
@@ -49,13 +46,13 @@ addr=0x0 \
 -netdev user,id=hostnet1 \
 -device 

[libvirt] [PATCH v3 11/18] qemu: assign virtio devices to PCIe slot when appropriate

[Laine Stump]

libvirt previously assigned nearly all devices to a "hotpluggable"
legacy PCI slot even on machines with a PCIe root bus (and even though
most such machines don't even support hotplug on legacy PCI slots!)
Forcing all devices onto legacy PCI slots means that the domain will
need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a
pci-bridge (to provide hotpluggable legacy PCI slots which, again,
usually aren't hotpluggable anyway).

To help reduce the need for these legacy controllers, this patch tries
to assign virtio-1.0-capable devices to PCIe slots whenever possible,
by setting appropriate connectFlags in
virDomainDeviceConnectFlagsInternal(). Happily, when that function was
written (just a few commits ago) it was created with a "virtioFlags"
argument, set by both of its callers, which is the proper connectFlags
to set for any virtio-*-pci device - depending on the arch/machinetype
of the domain, and whether or not the qemu binary supports virtio-1.0,
that flag will have either been set to PCI or PCIE. This patch merely
enables the functionality by setting the flags for the device to
whatever is in virtioFlags if the device is a virtio-*-pci device.

NB: since the slot must be hotpluggable, and pcie-root (the PCIe root
complex) does *not* support hotplug, this means that suitable
controllers must also be in the config (i.e. either pcie-root-port, or
pcie-downstream-port). For now, libvirt doesn't add those
automatically, so if you put virtio devices in a config for a qemu
that has PCIe-capable virtio devices, you'll need to add extra
pcie-root-ports yourself. That requirement will be eliminated in a
future patch, but for now, it's simple to do this:

   
   
   
   ...

Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
---
 src/qemu/qemu_domain_address.c |  39 --
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args  |  57 
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml   |  60 +
 .../qemuxml2argv-q35-virtio-pci.args   |  57 
 .../qemuxml2argv-q35-virtio-pci.xml|   1 +
 tests/qemuxml2argvtest.c   |  45 +++
 .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 149 +
 .../qemuxml2xmlout-q35-virtio-pci.xml  | 149 +
 tests/qemuxml2xmltest.c|  40 ++
 9 files changed, 586 insertions(+), 11 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args
 create mode 12 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.xml
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pci.xml

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index d811540..c8a8f6b 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -424,8 +424,7 @@ static virDomainPCIConnectFlags
 qemuDomainDeviceConnectFlagsInternal(virDomainDeviceDefPtr dev,
  virDomainPCIConnectFlags pcieFlags
  ATTRIBUTE_UNUSED,
- virDomainPCIConnectFlags virtioFlags
- ATTRIBUTE_UNUSED)
+ virDomainPCIConnectFlags virtioFlags)
 {
 virDomainPCIConnectFlags flags = VIR_PCI_CONNECT_TYPE_PCI_DEVICE;
 
@@ -439,16 +438,22 @@ 
qemuDomainDeviceConnectFlagsInternal(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_DEVICE_CONTROLLER: {
 virDomainControllerDefPtr cont = dev->data.controller;
 
-if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_FDC ||
-cont->type == VIR_DOMAIN_CONTROLLER_TYPE_CCID ||
-(cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
- cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE))
+if ((cont->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI &&
+ cont->model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI) ||
+cont->type == VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL) {
+flags = virtioFlags;
+} else if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_FDC ||
+   cont->type == VIR_DOMAIN_CONTROLLER_TYPE_CCID ||
+   (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
+cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE)) {
 flags = 0;
+}
 break;
 }
 
 case VIR_DOMAIN_DEVICE_FS:
 /* the only type of filesystem so far is virtio-9p-pci */
+flags = virtioFlags;
 break;
 
 case VIR_DOMAIN_DEVICE_NET: {
@@ -461,6 +466,8 @@ qemuDomainDeviceConnectFlagsInternal(virDomainDeviceDefPtr 
dev,
 if (net->type == VIR_DOMAIN_NET_TYPE_HOSTDEV ||
 

[libvirt] [PATCH v3 12/18] qemu: assign e1000e network devices to PCIe slots when appropriate

[Laine Stump]

The e1000e is an emulated network device based on the Intel 82574,
present in qemu 2.7.0 and later. Among other differences from the
e1000, it presents itself as a PCIe device rather than legacy PCI. In
order to get it assigned to a PCIe controller, this patch updates the
flags setting for network devices when the model name is "e1000e".

(Note that for some reason libvirt has never validated the network
device model names other than to check that there are no dangerous
characters in them. That should probably change, but is the subject of
another patch.)

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1343094
---
 src/qemu/qemu_domain_address.c |  2 ++
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args  | 24 +++
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml   |  5 
 .../qemuxml2argv-q35-virtio-pci.args   |  4 
 .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 28 +++---
 .../qemuxml2xmlout-q35-virtio-pci.xml  | 10 
 6 files changed, 54 insertions(+), 19 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index c8a8f6b..e11a23b 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -468,6 +468,8 @@ qemuDomainDeviceConnectFlagsInternal(virDomainDeviceDefPtr 
dev,
 flags = 0;
 else if (STREQ(net->model, "virtio"))
 flags = virtioFlags;
+else if (STREQ(net->model, "e1000e"))
+flags = pcieFlags;
 break;
 }
 
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
index 2ea0c08..40c8063 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
@@ -29,15 +29,16 @@ QEMU_AUDIO_DRV=none \
 -device ioh3420,port=0x50,chassis=11,id=pci.11,bus=pcie.0,addr=0xa \
 -device ioh3420,port=0x58,chassis=12,id=pci.12,bus=pcie.0,addr=0xb \
 -device ioh3420,port=0x60,chassis=13,id=pci.13,bus=pcie.0,addr=0xc \
+-device ioh3420,port=0x68,chassis=14,id=pci.14,bus=pcie.0,addr=0xd \
 -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \
 -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,\
 addr=0x1d \
 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \
 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \
--device virtio-scsi-pci,id=scsi0,bus=pci.6,addr=0x0 \
--device virtio-serial-pci,id=virtio-serial0,bus=pci.5,addr=0x0 \
+-device virtio-scsi-pci,id=scsi0,bus=pci.7,addr=0x0 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.6,addr=0x0 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk1 \
--device virtio-blk-pci,bus=pci.7,addr=0x0,drive=drive-virtio-disk1,\
+-device virtio-blk-pci,bus=pci.8,addr=0x0,drive=drive-virtio-disk1,\
 id=virtio-disk1 \
 -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/export/to/guest \
 -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=/import/from/host,\
@@ -45,13 +46,16 @@ bus=pci.3,addr=0x0 \
 -netdev user,id=hostnet0 \
 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:11:22:33:44:55,bus=pci.4,\
 addr=0x0 \
--device virtio-input-host-pci,id=input0,evdev=/dev/input/event1234,bus=pci.10,\
+-netdev user,id=hostnet1 \
+-device e1000e,netdev=hostnet1,id=net1,mac=00:11:22:33:44:66,bus=pci.5,\
 addr=0x0 \
--device virtio-mouse-pci,id=input1,bus=pci.11,addr=0x0 \
--device virtio-keyboard-pci,id=input2,bus=pci.12,addr=0x0 \
--device virtio-tablet-pci,id=input3,bus=pci.13,addr=0x0 \
+-device virtio-input-host-pci,id=input0,evdev=/dev/input/event1234,bus=pci.11,\
+addr=0x0 \
+-device virtio-mouse-pci,id=input1,bus=pci.12,addr=0x0 \
+-device virtio-keyboard-pci,id=input2,bus=pci.13,addr=0x0 \
+-device virtio-tablet-pci,id=input3,bus=pci.14,addr=0x0 \
 -device virtio-vga,id=video0,bus=pcie.0,addr=0x1 \
--device virtio-balloon-pci,id=balloon0,bus=pci.8,addr=0x0 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.9,addr=0x0 \
 -object rng-random,id=objrng0,filename=/dev/urandom \
--device 
virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=123,period=1234,bus=pci.9,\
-addr=0x0
+-device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=123,period=1234,\
+bus=pci.10,addr=0x0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
index 7bed08c..39db5f0 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
@@ -28,6 +28,7 @@
 
 
 
+
 
 
 
@@ -45,6 +46,10 @@
   
   
 
+
+  
+  
+
 
 
   
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args
index 7cedc82..5723af7 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args

[libvirt] [PATCH v3 16/18] qemu: don't force-add a dmi-to-pci-bridge just on principle

[Laine Stump]

Now the a dmi-to-pci-bridge is automatically added just as it's needed
(when a pci-bridge is being added), we no longer have any need to
force-add one to every single Q35 domain.
---
 src/qemu/qemu_domain.c | 12 
 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args |  3 +-
 .../qemuxml2argv-q35-pcie-autoadd.args | 55 +++
 .../qemuxml2xmlout-pcie-root.xml   |  4 --
 .../qemuxml2xmlout-q35-pcie-autoadd.xml| 82 ++
 5 files changed, 67 insertions(+), 89 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 227134e..eed8cfe 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2084,18 +2084,6 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def,
  
VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)) {
 goto cleanup;
 }
-/* Add a dmi-to-pci-bridge bridge if there are no PCI controllers
- * other than the pcie-root. This is so that there will be 
hot-pluggable
- * PCI slots available.
- *
- * We skip this step for aarch64 mach-virt guests, where we want to
- * be able to have a pure virtio-mmio topology
- */
-if (virDomainControllerFind(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 1) < 
0 &&
-!qemuDomainMachineIsVirt(def) &&
-!virDomainDefAddController(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 1,
-   
VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE))
-goto cleanup;
 }
 
 if (addDefaultMemballoon && !def->memballoon) {
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args 
b/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
index 7ef03d3..59a849f 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
@@ -15,5 +15,4 @@ QEMU_AUDIO_DRV=none \
 -nodefaults \
 -monitor unix:/tmp/lib/domain--1-q35-test/monitor.sock,server,nowait \
 -no-acpi \
--boot c \
--device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
index 6bea3e4..7b6f040 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
@@ -16,42 +16,41 @@ QEMU_AUDIO_DRV=none \
 -monitor unix:/tmp/lib/domain--1-q35-test/monitor.sock,server,nowait \
 -no-acpi \
 -boot c \
--device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \
--device ioh3420,port=0x10,chassis=2,id=pci.2,bus=pcie.0,addr=0x2 \
--device ioh3420,port=0x18,chassis=3,id=pci.3,bus=pcie.0,addr=0x3 \
--device ioh3420,port=0x20,chassis=4,id=pci.4,bus=pcie.0,addr=0x4 \
--device ioh3420,port=0x28,chassis=5,id=pci.5,bus=pcie.0,addr=0x5 \
--device ioh3420,port=0x30,chassis=6,id=pci.6,bus=pcie.0,addr=0x6 \
--device ioh3420,port=0x38,chassis=7,id=pci.7,bus=pcie.0,addr=0x7 \
--device ioh3420,port=0x40,chassis=8,id=pci.8,bus=pcie.0,addr=0x8 \
--device ioh3420,port=0x48,chassis=9,id=pci.9,bus=pcie.0,addr=0x9 \
--device ioh3420,port=0x50,chassis=10,id=pci.10,bus=pcie.0,addr=0xa \
--device ioh3420,port=0x58,chassis=11,id=pci.11,bus=pcie.0,addr=0xb \
--device ioh3420,port=0x60,chassis=12,id=pci.12,bus=pcie.0,addr=0xc \
--device ioh3420,port=0x68,chassis=13,id=pci.13,bus=pcie.0,addr=0xd \
--device ioh3420,port=0x70,chassis=14,id=pci.14,bus=pcie.0,addr=0xe \
--device nec-usb-xhci,id=usb,bus=pci.7,addr=0x0 \
--device virtio-scsi-pci,id=scsi0,bus=pci.6,addr=0x0 \
--device virtio-serial-pci,id=virtio-serial0,bus=pci.5,addr=0x0 \
+-device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,addr=0x2 \
+-device ioh3420,port=0x18,chassis=2,id=pci.2,bus=pcie.0,addr=0x3 \
+-device ioh3420,port=0x20,chassis=3,id=pci.3,bus=pcie.0,addr=0x4 \
+-device ioh3420,port=0x28,chassis=4,id=pci.4,bus=pcie.0,addr=0x5 \
+-device ioh3420,port=0x30,chassis=5,id=pci.5,bus=pcie.0,addr=0x6 \
+-device ioh3420,port=0x38,chassis=6,id=pci.6,bus=pcie.0,addr=0x7 \
+-device ioh3420,port=0x40,chassis=7,id=pci.7,bus=pcie.0,addr=0x8 \
+-device ioh3420,port=0x48,chassis=8,id=pci.8,bus=pcie.0,addr=0x9 \
+-device ioh3420,port=0x50,chassis=9,id=pci.9,bus=pcie.0,addr=0xa \
+-device ioh3420,port=0x58,chassis=10,id=pci.10,bus=pcie.0,addr=0xb \
+-device ioh3420,port=0x60,chassis=11,id=pci.11,bus=pcie.0,addr=0xc \
+-device ioh3420,port=0x68,chassis=12,id=pci.12,bus=pcie.0,addr=0xd \
+-device ioh3420,port=0x70,chassis=13,id=pci.13,bus=pcie.0,addr=0xe \
+-device nec-usb-xhci,id=usb,bus=pci.6,addr=0x0 \
+-device virtio-scsi-pci,id=scsi0,bus=pci.5,addr=0x0 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk1 \
--device virtio-blk-pci,bus=pci.8,addr=0x0,drive=drive-virtio-disk1,\
+-device virtio-blk-pci,bus=pci.7,addr=0x0,drive=drive-virtio-disk1,\
 id=virtio-disk1 \
 -fsdev 

[libvirt] [PATCH v3 14/18] qemu: only force an available legacy-PCI slot on domains with pci-root

[Laine Stump]

Andrea had the right idea when he disabled the "reserve an extra
unused slot" bit for aarch64/virt. For *any* PCI Express-based
machine, it is pointless since 1) an extra legacy-PCI slot can't be
used for hotplug, since hotplug into legacy PCI slots doesn't work on
PCI Express machinetypes, and 2) even for "coldplug" expansion,
everybody will want to expand using Express controllers, not legacy
PCI.

This patch eliminates the extra slot reserve unless the system has a
pci-root (i.e. legacy PCI).
---
 src/qemu/qemu_domain_address.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 83e3861..1ff80e3 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1713,16 +1713,17 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
 buses_reserved = false;
 }
 
-/* Reserve 1 extra slot for a (potential) bridge only if buses
- * are not fully reserved yet.
+/* Reserve 1 extra slot for a (potential) bridge (for future
+ * expansion) only if buses are not fully reserved yet.
  *
- * We don't reserve the extra slot for aarch64 mach-virt guests
- * either because we want to be able to have pure virtio-mmio
- * guests, and reserving this slot would force us to add at least
- * a dmi-to-pci-bridge to an otherwise PCI-free topology
+ * We only do this for those domains that have pci-root, since
+ * those with pcie-root will usually want to expand using PCIe
+ * controllers, and we don't want to saddle all PCIe domains
+ * down with a dmi-to-pci-bridge *and* a pci-bridge when they
+ * will probably never use it.
  */
 if (!buses_reserved &&
-!qemuDomainMachineIsVirt(def) &&
+qemuDomainMachineHasPCIRoot(def) &&
 qemuDomainPCIAddressReserveNextSlot(addrs, ) < 0)
 goto cleanup;
 
-- 
2.7.4

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

[libvirt] [PATCH v3 03/18] qemu: new functions qemuDomainMachineHasPCI[e]Root()

[Laine Stump]

These functions provide a simple one line method of learning if the
current domain has a pci-root or pcie-root bus.
---
 src/qemu/qemu_domain.c | 28 
 src/qemu/qemu_domain.h |  2 ++
 2 files changed, 30 insertions(+)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 3f16dbe..227134e 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5263,6 +5263,34 @@ qemuDomainMachineIsI440FX(const virDomainDef *def)
 
 
 bool
+qemuDomainMachineHasPCIRoot(const virDomainDef *def)
+{
+int root = virDomainControllerFind(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 0);
+
+if (root < 0)
+return false;
+
+if (def->controllers[root]->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT)
+return true;
+return false;
+}
+
+
+bool
+qemuDomainMachineHasPCIeRoot(const virDomainDef *def)
+{
+int root = virDomainControllerFind(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 0);
+
+if (root < 0)
+return false;
+
+if (def->controllers[root]->model == VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)
+return true;
+return false;
+}
+
+
+bool
 qemuDomainMachineNeedsFDC(const virDomainDef *def)
 {
 char *p = STRSKIP(def->os.machine, "pc-q35-");
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index a1404d0..5b97c8c 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -637,6 +637,8 @@ virDomainChrDefPtr qemuFindAgentConfig(virDomainDefPtr def);
 
 bool qemuDomainMachineIsQ35(const virDomainDef *def);
 bool qemuDomainMachineIsI440FX(const virDomainDef *def);
+bool qemuDomainMachineHasPCIRoot(const virDomainDef *def);
+bool qemuDomainMachineHasPCIeRoot(const virDomainDef *def);
 bool qemuDomainMachineNeedsFDC(const virDomainDef *def);
 bool qemuDomainMachineIsS390CCW(const virDomainDef *def);
 bool qemuDomainMachineIsVirt(const virDomainDef *def);
-- 
2.7.4

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

[libvirt] [PATCH v3 08/18] qemu: replace calls to virDomainPCIAddressReserveNext*() with static function

[Laine Stump]

An upcoming commit will remove the "flag" argument from all the calls
to reserve the next available address|slot, but I don't want to change
the arguments in the hypervisor-agnostic
virDomainPCIAddressReserveNext*() functions, so this patch places a
simple qemu-specific wrapper around those functions - the new
functions don't take a flags arg, but grab it from the device's
info->pciConnectFlags.
---
 src/qemu/qemu_domain_address.c | 92 ++
 1 file changed, 57 insertions(+), 35 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 5a19f0b..7de081b 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -656,6 +656,27 @@ qemuDomainDeviceSetAllConnectFlags(virDomainDefPtr def,
 
 
 static int
+qemuDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
+virDomainDeviceInfoPtr dev,
+virDomainPCIConnectFlags flags,
+unsigned int function,
+bool reserveEntireSlot)
+{
+return virDomainPCIAddressReserveNextAddr(addrs, dev, flags,
+  function, reserveEntireSlot);
+}
+
+
+static int
+qemuDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
+virDomainDeviceInfoPtr dev,
+virDomainPCIConnectFlags flags)
+{
+return qemuDomainPCIAddressReserveNextAddr(addrs, dev, flags, 0, true);
+}
+
+
+static int
 qemuDomainCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
 virDomainDeviceDefPtr device,
 virDomainDeviceInfoPtr info,
@@ -940,7 +961,7 @@ qemuDomainValidateDevicePCISlotsPIIX3(virDomainDefPtr def,
 
 if (virDomainPCIAddressSlotInUse(addrs, _addr)) {
 if (qemuDeviceVideoUsable) {
-if (virDomainPCIAddressReserveNextSlot(addrs,
+if (qemuDomainPCIAddressReserveNextSlot(addrs,
>info,
flags) < 0)
 goto cleanup;
@@ -1133,7 +1154,7 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def,
 
 if (virDomainPCIAddressSlotInUse(addrs, _addr)) {
 if (qemuDeviceVideoUsable) {
-if (virDomainPCIAddressReserveNextSlot(addrs,
+if (qemuDomainPCIAddressReserveNextSlot(addrs,
>info,
flags) < 0)
 goto cleanup;
@@ -1274,7 +1295,8 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
  * controller/bus to connect it to on the upstream side.
  */
 flags = virDomainPCIControllerModelToConnectType(model);
-if (virDomainPCIAddressReserveNextSlot(addrs, >info, flags) 
< 0)
+if (qemuDomainPCIAddressReserveNextSlot(addrs, >info,
+flags) < 0)
 goto error;
 }
 }
@@ -1292,8 +1314,8 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 
 /* Only support VirtIO-9p-pci so far. If that changes,
  * we might need to skip devices here */
-if (virDomainPCIAddressReserveNextSlot(addrs, >fss[i]->info,
-   flags) < 0)
+if (qemuDomainPCIAddressReserveNextSlot(addrs, >fss[i]->info,
+flags) < 0)
 goto error;
 }
 
@@ -1307,8 +1329,8 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 !virDeviceInfoPCIAddressWanted(>nets[i]->info)) {
 continue;
 }
-if (virDomainPCIAddressReserveNextSlot(addrs, >nets[i]->info,
-   flags) < 0)
+if (qemuDomainPCIAddressReserveNextSlot(addrs, >nets[i]->info,
+flags) < 0)
 goto error;
 }
 
@@ -1322,8 +1344,8 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 def->sounds[i]->model == VIR_DOMAIN_SOUND_MODEL_USB)
 continue;
 
-if (virDomainPCIAddressReserveNextSlot(addrs, >sounds[i]->info,
-   flags) < 0)
+if (qemuDomainPCIAddressReserveNextSlot(addrs, >sounds[i]->info,
+flags) < 0)
 goto error;
 }
 
@@ -1399,14 +1421,15 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 } else {
 /* This is the first part of the controller, so need
  * to find a free slot & then reserve this function */
-if 

[libvirt] [PATCH v3 05/18] conf: new function virDomainPCIAddressReserveNextAddr()

[Laine Stump]

There is an existing virDomainPCIAddressReserveNextSlot() which will
reserve all functions of the next available PCI slot. One place in the
qemu PCI address assignment code requires reserving a *single*
function of the next available PCI slot. This patch modifies and
renames virDomainPCIAddressReserveNextSlot() so that it can fulfill
both the original purpose and the need to reserve a single function.

(This is being done so that the abovementioned code in qemu can have
its "kind of open coded" solution replaced with a call to this new
function).
---
 src/conf/domain_addr.c   | 50 +++-
 src/conf/domain_addr.h   |  7 +++
 src/libvirt_private.syms |  1 +
 3 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index cff2c3b..f735fb4 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -691,29 +691,69 @@ virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr 
addrs,
 return 0;
 }
 
+/**
+ * virDomainPCIAddressReserveNextAddr:
+ *
+ *find the next *completely unreserved* slot with compatible
+ *connection @flags, and mark either one function or the entire
+ *slot (according to @function and @reserveEntireSlot).
+ *
+ * @addrs: a set of addresses - one bit for each function on each
+ * slot on each bus, set if in use, clear if not in use.
+ *
+ * @dev:   virDomainDeviceInfo that should get the new address set.
+ *
+ * @flags: CONNECT_TYPE flags for the port we're looking for
+ *
+ * @function:  which function on the slot to mark as reserved
+ * (if @reserveEntireSlot is false)
+ *
+ * @reserveEntireSlot: true to reserve all functions on the new slot,
+ *  false to reserve just @function
+ *
+ *
+ * returns 0 (and dev->addr.pci set) on success, or -1 on failure.
+ */
 int
-virDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
+virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev,
-   virDomainPCIConnectFlags flags)
+   virDomainPCIConnectFlags flags,
+   unsigned int function,
+   bool reserveEntireSlot)
 {
 virPCIDeviceAddress addr;
+
 if (virDomainPCIAddressGetNextSlot(addrs, , flags) < 0)
 return -1;
 
-if (virDomainPCIAddressReserveSlot(addrs, , flags) < 0)
+addr.function = reserveEntireSlot ? 0 : function;
+
+if (virDomainPCIAddressReserveAddr(addrs, , flags, reserveEntireSlot, 
false) < 0)
 return -1;
 
+addrs->lastaddr = addr;
+addrs->lastaddr.function = 0;
+addrs->lastaddr.multi = VIR_TRISTATE_SWITCH_ABSENT;
+addrs->lastFlags = flags;
+
 if (!addrs->dryRun) {
 dev->type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
 dev->addr.pci = addr;
 }
 
-addrs->lastaddr = addr;
-addrs->lastFlags = flags;
 return 0;
 }
 
 
+int
+virDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
+   virDomainDeviceInfoPtr dev,
+   virDomainPCIConnectFlags flags)
+{
+return virDomainPCIAddressReserveNextAddr(addrs, dev, flags, 0, true);
+}
+
+
 static char*
 virDomainCCWAddressAsString(virDomainDeviceCCWAddressPtr addr)
 {
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 0072a08..904d060 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -160,6 +160,13 @@ int 
virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr addrs,
virDomainPCIConnectFlags flags)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
+int virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
+   virDomainDeviceInfoPtr dev,
+   virDomainPCIConnectFlags flags,
+   unsigned int function,
+   bool reserveEntireSlot)
+ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
+
 int virDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev,
virDomainPCIConnectFlags flags)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 9610e0c..34ea3c6 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -99,6 +99,7 @@ virDomainPCIAddressFlagsCompatible;
 virDomainPCIAddressGetNextSlot;
 virDomainPCIAddressReleaseSlot;
 virDomainPCIAddressReserveAddr;
+virDomainPCIAddressReserveNextAddr;
 virDomainPCIAddressReserveNextSlot;
 virDomainPCIAddressReserveSlot;
 virDomainPCIAddressSetAlloc;
-- 
2.7.4

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

[libvirt] [PATCH v3 04/18] qemu: new functions qemuDomainDeviceConnectFlags*()

[Laine Stump]

The lowest level function of this trio aims to be the ultimate
authority for the virDomainPCIConnectFlags to use for any given device
using a particular arch/machinetype/qemu-binary.

qemuDomainDeviceConnectFlagsInternal() returns the flags

qemuDomainDeviceConnectFlags() sets info->pciConnectFlags in a single
device (unless it has no virDomainDeviceInfo, in which case it's a
NOP).

qemuDomainDeviceSetAllConnectFlags() sets info->pciConnectFlags in all
devices that have a virDomainDeviceInfo (using
virDomainDeviceInfoIterate())

The latter two functions aren't called anywhere yet. This commit is
just making them available.
---
 src/conf/device_conf.h |   5 +
 src/qemu/qemu_domain_address.c | 257 +
 2 files changed, 262 insertions(+)

diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index 8443de6..f435fb5 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -142,6 +142,11 @@ typedef struct _virDomainDeviceInfo {
 /* bootIndex is only used for disk, network interface, hostdev
  * and redirdev devices */
 unsigned int bootIndex;
+
+/* pciConnectFlags is only used internally during address
+ * assignment, never saved and never reported.
+ */
+int pciConnectFlags; /* enum virDomainPCIConnectFlags */
 } virDomainDeviceInfo, *virDomainDeviceInfoPtr;
 
 
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index dc4e4ee..7f86c32 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -398,6 +398,263 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr 
def,
 }
 
 
+/**
+ *  qemuDomainDeviceConnectFlagsInternal:
+ *
+ *  Lowest level function to determine PCI connectFlags for a
+ *  device. Assume HOTPLUGGABLE | PCI_ENDPOINT, then modify
+ *  appropriately for exceptions. This function relies on the next
+ *  higher-level function determining the value for pcieFlags and
+ *  virtioFlags in advance - this is to make it more efficient to call
+ *  multiple times.
+ *
+ *  @dev: The device to be checked
+ *
+ *  @pcieFlags: flags to use for a known PCI Express device
+ *
+ *  @virtioFlags: flags to use for a virtio device (properly vetted
+ *for the current qemu binary and arch/machinetype)
+ *
+ *  returns appropriate virDomainPCIConnectFlags for this device in
+ *  this domain, or 0 if the device doesn't connect using PCI. There
+ *  is no failure.
+ *
+ */
+static virDomainPCIConnectFlags
+qemuDomainDeviceConnectFlagsInternal(virDomainDeviceDefPtr dev,
+ virDomainPCIConnectFlags pcieFlags
+ ATTRIBUTE_UNUSED,
+ virDomainPCIConnectFlags virtioFlags
+ ATTRIBUTE_UNUSED)
+{
+virDomainPCIConnectFlags flags = VIR_PCI_CONNECT_TYPE_PCI_DEVICE;
+
+/* Get these out of the way to simplify the rest */
+if (dev->type == VIR_DOMAIN_DEVICE_CONTROLLER &&
+dev->data.controller->type == VIR_DOMAIN_CONTROLLER_TYPE_PCI)
+return 
virDomainPCIControllerModelToConnectType(dev->data.controller->model);
+
+/* remember - default flags is PCI_DEVICE, so only set if it's different. 
*/
+switch (dev->type) {
+case VIR_DOMAIN_DEVICE_CONTROLLER: {
+virDomainControllerDefPtr cont = dev->data.controller;
+
+if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_FDC ||
+cont->type == VIR_DOMAIN_CONTROLLER_TYPE_CCID ||
+(cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
+ cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE))
+flags = 0;
+break;
+}
+
+case VIR_DOMAIN_DEVICE_FS:
+/* the only type of filesystem so far is virtio-9p-pci */
+break;
+
+case VIR_DOMAIN_DEVICE_NET: {
+virDomainNetDefPtr net = dev->data.net;
+
+/* NB: a type='hostdev' will use PCI, but its
+ * address is assigned when we're assigning the
+ * addresses for other hostdev devices.
+ */
+if (net->type == VIR_DOMAIN_NET_TYPE_HOSTDEV ||
+STREQ(net->model, "usb-net"))
+flags = 0;
+break;
+}
+
+case VIR_DOMAIN_DEVICE_SOUND:
+switch (dev->data.sound->model) {
+case VIR_DOMAIN_SOUND_MODEL_SB16:
+case VIR_DOMAIN_SOUND_MODEL_PCSPK:
+case VIR_DOMAIN_SOUND_MODEL_USB:
+flags = 0;
+break;
+}
+break;
+
+case VIR_DOMAIN_DEVICE_DISK:
+if (dev->data.disk->bus != VIR_DOMAIN_DISK_BUS_VIRTIO)
+flags = 0; /* only virtio disks use PCI */
+break;
+
+case VIR_DOMAIN_DEVICE_HOSTDEV:
+break;
+
+case VIR_DOMAIN_DEVICE_MEMBALLOON:
+if (dev->data.memballoon->model != VIR_DOMAIN_MEMBALLOON_MODEL_VIRTIO)
+flags = 0;
+break;
+
+case VIR_DOMAIN_DEVICE_RNG:
+if (dev->data.rng->model != VIR_DOMAIN_RNG_MODEL_VIRTIO)
+flags = 0;

[libvirt] [PATCH v3 10/18] qemu: set/use proper pciConnectFlags during hotplug

[Laine Stump]

Before now, all the qemu hotplug functions assumed that all devices to
be hotplugged were legacy PCI endpoint devices
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all
devices *are* legacy PCI endpoint devices on x86/440fx machinetypes,
and hotplug didn't work properly on machinetypes using PCIe anyway
(hotplugging onto a legacy PCI slot doesn't work, and until commit
b87703cf any attempt to manually specify a PCIe address for a
hotplugged device would be erroneously rejected).

This patch makes all qemu hotplug operations honor the pciConnectFlags
set by the single all-knowing function
qemuDomainDeviceConnectFlagsInternal(). This is done in 3 steps, but
in a single commit since we would have to touch the other points at
each step anyway:

1) add a flags argument to the hypervisor-agnostic
virDomainPCIAddressEnsureAddr() (previously it hardcoded
..._PCI_DEVICE)

2) add a new qemu-specific function qemuDomainEnsurePCIAddress() which
gets the correct pciConnectFlags for the device from
qemuDomainDeviceConnectFlags(), then calls
virDomainPCIAddressEnsureAddr().

3) in qemu_hotplug.c replace all calls to
virDomainPCIAddressEnsureAddr() with calls to
qemuDomainEnsurePCIAddress()

So in effect, we're putting a "shim" on top of all calls to
virDomainPCIAddressEnsureAddr() that sets the right pciConnectFlags.
---
 src/conf/domain_addr.c | 16 
 src/conf/domain_addr.h |  3 ++-
 src/qemu/qemu_domain_address.c | 27 +++
 src/qemu/qemu_domain_address.h |  4 
 src/qemu/qemu_hotplug.c| 25 +
 5 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index be42f15..12b5cb2 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -485,17 +485,17 @@ virDomainPCIAddressReserveSlot(virDomainPCIAddressSetPtr 
addrs,
 
 int
 virDomainPCIAddressEnsureAddr(virDomainPCIAddressSetPtr addrs,
-  virDomainDeviceInfoPtr dev)
+  virDomainDeviceInfoPtr dev,
+  virDomainPCIConnectFlags flags)
 {
 int ret = -1;
 char *addrStr = NULL;
-/* Flags should be set according to the particular device,
- * but only the caller knows the type of device. Currently this
- * function is only used for hot-plug, though, and hot-plug is
- * only supported for standard PCI devices, so we can safely use
- * the setting below */
-virDomainPCIConnectFlags flags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-  VIR_PCI_CONNECT_TYPE_PCI_DEVICE);
+
+/* if pciConnectFlags is 0, the particular model of this device
+ * on this machinetype doesn't need a PCI address, so we're done.
+ */
+if (!flags)
+   return 0;
 
 if (!(addrStr = virDomainPCIAddressAsString(>addr.pci)))
 goto cleanup;
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 4d6d12a..92ee04c 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -144,7 +144,8 @@ int 
virDomainPCIAddressReserveSlot(virDomainPCIAddressSetPtr addrs,
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
 int virDomainPCIAddressEnsureAddr(virDomainPCIAddressSetPtr addrs,
-  virDomainDeviceInfoPtr dev)
+  virDomainDeviceInfoPtr dev,
+  virDomainPCIConnectFlags flags)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
 int virDomainPCIAddressReleaseAddr(virDomainPCIAddressSetPtr addrs,
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index ed728f5..d811540 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -2032,6 +2032,33 @@ qemuDomainAssignAddresses(virDomainDefPtr def,
 return 0;
 }
 
+/**
+ * qemuDomainEnsurePCIAddress:
+ *
+ * if @dev should have a PCI address but doesn't, assign
+ * an address on a compatible PCI bus. Validate that any
+ * existing address is on a compatible bus.
+ *
+ * @obj: the virDomainObjPtr for the domain. This will include
+ *   qemuCaps and address cache (if there is one)
+ *
+ * @dev: the device that we need to ensure has a PCI address
+ *
+ * returns 0 on success (and any new address set in dev->...info) -1
+ * on failure.
+ */
+int
+qemuDomainEnsurePCIAddress(virDomainObjPtr obj,
+   virDomainDeviceDefPtr dev)
+{
+qemuDomainObjPrivatePtr priv = obj->privateData;
+virDomainDeviceInfoPtr info = virDomainDeviceGetInfo(dev);
+
+qemuDomainDeviceConnectFlags(obj->def, dev, priv->qemuCaps);
+
+return virDomainPCIAddressEnsureAddr(priv->pciaddrs, info,
+ info->pciConnectFlags);
+}
 
 void
 qemuDomainReleaseDeviceAddress(virDomainObjPtr vm,
diff --git a/src/qemu/qemu_domain_address.h b/src/qemu/qemu_domain_address.h
index 11d6e92..800859c 100644
--- a/src/qemu/qemu_domain_address.h
+++ 

[libvirt] [PATCH v3 07/18] conf: make virDomainPCIAddressGetNextSlot() a local static function

[Laine Stump]

This function is no longer needed outside of domain_addr.c.
---
 src/conf/domain_addr.c   | 2 +-
 src/conf/domain_addr.h   | 5 -
 src/libvirt_private.syms | 1 -
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index f735fb4..be42f15 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -591,7 +591,7 @@ virDomainPCIAddressSetFree(virDomainPCIAddressSetPtr addrs)
 }
 
 
-int
+static int
 virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr addrs,
virPCIDeviceAddressPtr next_addr,
virDomainPCIConnectFlags flags)
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 904d060..4d6d12a 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -155,11 +155,6 @@ int 
virDomainPCIAddressReleaseSlot(virDomainPCIAddressSetPtr addrs,
virPCIDeviceAddressPtr addr)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
-int virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr addrs,
-   virPCIDeviceAddressPtr next_addr,
-   virDomainPCIConnectFlags flags)
-ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
-
 int virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev,
virDomainPCIConnectFlags flags,
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 34ea3c6..8ac2e79 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -96,7 +96,6 @@ virDomainPCIAddressAsString;
 virDomainPCIAddressBusSetModel;
 virDomainPCIAddressEnsureAddr;
 virDomainPCIAddressFlagsCompatible;
-virDomainPCIAddressGetNextSlot;
 virDomainPCIAddressReleaseSlot;
 virDomainPCIAddressReserveAddr;
 virDomainPCIAddressReserveNextAddr;
-- 
2.7.4

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

[libvirt] [PATCH v3 01/18] conf: restrict what type of buses will accept a pci-bridge

[Laine Stump]

A pci-bridge has *almost* the same rules as a legacy PCI endpoint
device for where it can be automatically connected, and until now both
had been considered identical. There is one pairing that is okay when
specifically requested by the user (i.e. manual assignment), but we
want to avoid it when auto-assigning addresses - plugging a pci-bridge
directly into pcie-root (it is cleaner to plug in a dmi-to-pci-bridge,
then plug the pci-bridge into that).

In order to allow that difference, this patch makes a separate
CONNECT_TYPE for pci-bridge, and uses it to restrict auto-assigned
addresses for pci-bridges to be only on pci-root, pci-expander-bus,
dmi-to-pci-bridge, or on another pci-bridge.

NB: As with other discouraged-but-seem-to-work configurations
(e.g. plugging a legacy PCI device into a pcie-root-port) if someone
*really* wants to, they can still force a pci-bridge to be plugged
into pcie-root (by manually specifying its PCI address.)
---
 src/conf/domain_addr.c | 24 
 src/conf/domain_addr.h |  4 +++-
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 93026c2..cff2c3b 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -51,11 +51,7 @@ 
virDomainPCIControllerModelToConnectType(virDomainControllerModelPCI model)
 return 0;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
-/* pci-bridge is treated like a standard
- * PCI endpoint device, because it can plug into any
- * standard PCI slot (it just can't be hotplugged).
- */
-return VIR_PCI_CONNECT_TYPE_PCI_DEVICE;
+return VIR_PCI_CONNECT_TYPE_PCI_BRIDGE;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
 return VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS;
@@ -110,6 +106,12 @@ virDomainPCIAddressFlagsCompatible(virPCIDeviceAddressPtr 
addr,
  */
 if (devFlags & VIR_PCI_CONNECT_HOTPLUGGABLE)
 busFlags |= VIR_PCI_CONNECT_HOTPLUGGABLE;
+/* if the device is a pci-bridge, allow manually
+ * assigning to any bus that would also accept a
+ * standard PCI device.
+ */
+if (devFlags & VIR_PCI_CONNECT_TYPE_PCI_BRIDGE)
+devFlags |= VIR_PCI_CONNECT_TYPE_PCI_DEVICE;
 }
 
 /* If this bus doesn't allow the type of connection (PCI
@@ -138,6 +140,8 @@ virDomainPCIAddressFlagsCompatible(virPCIDeviceAddressPtr 
addr,
 connectStr = "pci-expander-bus";
 } else if (devFlags & VIR_PCI_CONNECT_TYPE_PCIE_EXPANDER_BUS) {
 connectStr = "pcie-expander-bus";
+} else if (devFlags & VIR_PCI_CONNECT_TYPE_PCI_BRIDGE) {
+connectStr = "pci-bridge";
 } else {
 /* this should never happen. If it does, there is a
  * bug in the code that sets the flag bits for devices.
@@ -247,19 +251,22 @@ virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr 
bus,
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
 bus->flags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
   VIR_PCI_CONNECT_TYPE_PCI_DEVICE |
+  VIR_PCI_CONNECT_TYPE_PCI_BRIDGE |
   VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS);
 bus->minSlot = 1;
 bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST;
 break;
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE:
 bus->flags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-  VIR_PCI_CONNECT_TYPE_PCI_DEVICE);
+  VIR_PCI_CONNECT_TYPE_PCI_DEVICE |
+  VIR_PCI_CONNECT_TYPE_PCI_BRIDGE);
 bus->minSlot = 1;
 bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST;
 break;
 case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS:
 bus->flags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-  VIR_PCI_CONNECT_TYPE_PCI_DEVICE);
+  VIR_PCI_CONNECT_TYPE_PCI_DEVICE |
+  VIR_PCI_CONNECT_TYPE_PCI_BRIDGE);
 bus->minSlot = 0;
 bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST;
 break;
@@ -280,7 +287,8 @@ virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr 
bus,
 case VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE:
 /* slots 0 - 31, standard PCI slots,
  * but *not* hot-pluggable */
-bus->flags = VIR_PCI_CONNECT_TYPE_PCI_DEVICE;
+bus->flags = (VIR_PCI_CONNECT_TYPE_PCI_DEVICE |
+  VIR_PCI_CONNECT_TYPE_PCI_BRIDGE);
 bus->minSlot = 0;
 bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST;
 break;
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 596cd4c..0072a08 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -43,6 +43,7 @@ typedef enum {
VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE = 1 << 6,
VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS = 1 << 7,
VIR_PCI_CONNECT_TYPE_PCIE_EXPANDER_BUS = 1 << 8,
+   VIR_PCI_CONNECT_TYPE_PCI_BRIDGE = 1 << 9,
 } virDomainPCIConnectFlags;
 
 /* a 

[libvirt] [PATCH v3 02/18] qemu: replace a lot of "def->controllers[i]" with equivalent "cont"

[Laine Stump]

There's no functional change here. This pointer was just used so many
times that the extra long lines became annoying.
---
 src/qemu/qemu_domain_address.c | 100 +
 1 file changed, 51 insertions(+), 49 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index bb16738..dc4e4ee 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -743,36 +743,38 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def,
 virDomainPCIConnectFlags flags = VIR_PCI_CONNECT_TYPE_PCIE_DEVICE;
 
 for (i = 0; i < def->ncontrollers; i++) {
-switch (def->controllers[i]->type) {
+virDomainControllerDefPtr cont = def->controllers[i];
+
+switch (cont->type) {
 case VIR_DOMAIN_CONTROLLER_TYPE_SATA:
 /* Verify that the first SATA controller is at 00:1F.2 the
  * q35 machine type *always* has a SATA controller at this
  * address.
  */
-if (def->controllers[i]->idx == 0) {
-if 
(virDeviceInfoPCIAddressPresent(>controllers[i]->info)) {
-if (def->controllers[i]->info.addr.pci.domain != 0 ||
-def->controllers[i]->info.addr.pci.bus != 0 ||
-def->controllers[i]->info.addr.pci.slot != 0x1F ||
-def->controllers[i]->info.addr.pci.function != 2) {
+if (cont->idx == 0) {
+if (virDeviceInfoPCIAddressPresent(>info)) {
+if (cont->info.addr.pci.domain != 0 ||
+cont->info.addr.pci.bus != 0 ||
+cont->info.addr.pci.slot != 0x1F ||
+cont->info.addr.pci.function != 2) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Primary SATA controller must have 
PCI address 0:0:1f.2"));
 goto cleanup;
 }
 } else {
-def->controllers[i]->info.type = 
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
-def->controllers[i]->info.addr.pci.domain = 0;
-def->controllers[i]->info.addr.pci.bus = 0;
-def->controllers[i]->info.addr.pci.slot = 0x1F;
-def->controllers[i]->info.addr.pci.function = 2;
+cont->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
+cont->info.addr.pci.domain = 0;
+cont->info.addr.pci.bus = 0;
+cont->info.addr.pci.slot = 0x1F;
+cont->info.addr.pci.function = 2;
 }
 }
 break;
 
 case VIR_DOMAIN_CONTROLLER_TYPE_USB:
-if ((def->controllers[i]->model
+if ((cont->model
  == VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_UHCI1) &&
-(def->controllers[i]->info.type
+(cont->info.type
  == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)) {
 /* Try to assign the first found USB2 controller to
  * 00:1D.0 and 2nd to 00:1A.0 (because that is their
@@ -798,21 +800,21 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def,
 if (virDomainPCIAddressReserveAddr(addrs, _addr,
flags, false, true) < 0)
 goto cleanup;
-def->controllers[i]->info.type
+cont->info.type
 = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
-def->controllers[i]->info.addr.pci.domain = 0;
-def->controllers[i]->info.addr.pci.bus = 0;
-def->controllers[i]->info.addr.pci.slot = tmp_addr.slot;
-def->controllers[i]->info.addr.pci.function = 0;
-def->controllers[i]->info.addr.pci.multi
+cont->info.addr.pci.domain = 0;
+cont->info.addr.pci.bus = 0;
+cont->info.addr.pci.slot = tmp_addr.slot;
+cont->info.addr.pci.function = 0;
+cont->info.addr.pci.multi
= VIR_TRISTATE_SWITCH_ON;
 }
 }
 break;
 
 case VIR_DOMAIN_CONTROLLER_TYPE_PCI:
-if (def->controllers[i]->model == 
VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE &&
-def->controllers[i]->info.type == 
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
+if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE &&
+cont->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
 /* Try to assign this bridge to 00:1E.0 (because that
 * is its standard location on real hardware) unless
 * it's already taken, but don't insist on it.
@@ -823,11 +825,11 @@ 

[libvirt] [PATCH v3 00/18] Use mode PCIe less legacy PCI

[Laine Stump]

(this time with auto-root-port-add goodness!)

Last month I posted a short patch series that attempted to auto-assign
addresses on PCI Express controllers to devices that were PCI Express
devices.

  https://www.redhat.com/archives/libvir-list/2016-August/msg00732.html

In particular, it would assign PCI virtio-1.0 devices, e1000e network
devices, and nec-usb-xhci devices to hotpluggable PCIe express ports
*if any were available*. However, a basic PCIe machine doesn't have
any hotpluggable PCIe ports, and the patchset I sent had no provision
for automatically adding any.

This new patchset takes care of that limitation by automatically
adding pci-root-ports as they are needed, and also automatically adds
a dmi-to-pci-bridge device (to create a legacy PCI bus hierarchy) when
needed so that we can do away with the code that *always* adds one
(and there is a patch that *does* do away with that code :-).

Once all of that was done, it turned out that virt-manager could
create an *almost* legacy-PCI-free Q35 domain config - the only legacy
PCI device was the sound device. Since the ich9 sound device is
integrated into the Intel ich9 chip (which is part of real Q35
hardware), as a curiousity I made an RFC patch that attempts to place
any ich9 audio device at 00:1B.0, which is the address where real Q35
hardware puts this device. With that patch in place, all you have to
do to get a legacy-free Q35 config out of virt-manager is switch the
sound device model from ich6 to ich9. (I don't expect that patch will
be pushed, but it's nice to see this result).

Although Andrea had ACKed most of the patches in the last patchset, I
hadn't wanted to push them without accompanying patches to auto-add
the pcie-root-ports (since doing so would render virt-manager +
new libvirt unusable for Q35 domains). Since then I've decided on a
cleaner manner for setting device connectFlags, so all but Patch 1 of
the last set was discarded and re-written from scratch.

Although there are still a couple more things I'd like to do, these
patches can be pushed without a serious regression in functionality
for Q35 domains:

1) currently I put each new pcie-root-port on its own slot, rather
than putting 8 of them on the different functions of a single
slot. This means you can only get ~30 devices before you have to start
manually adding pcie controllers. That will be remedied soon.

2) I don't have a patch yet to read a PCI device's capabilities to see
whether or not it is an Express device and change the connectFlags
accordingly. In the meantime if you want to plug in a vfio assigned
device, you'll either need to manually address it to a PCIe port, or
you'll need to manually add a pci-bridge device to the config.

3) I don't do anything to assure there are any unused pcie-root-ports
available for hotplug. We need to fix that, but I'm not sure how many
to "reserve". Suggestions I've heard have been "1", "2", "4", and
"just add pcie-root-ports 8 at a time and you'll have 'something
between 1 and 8' available".

Laine Stump (18):
  conf: restrict what type of buses will accept a pci-bridge
  qemu: replace a lot of "def->controllers[i]" with equivalent "cont"
  qemu: new functions qemuDomainMachineHasPCI[e]Root()
  qemu: new functions qemuDomainDeviceConnectFlags*()
  conf: new function virDomainPCIAddressReserveNextAddr()
  qemu: use virDomainPCIAddressReserveNextAddr in
qemuDomainAssignDevicePCISlots
  conf: make virDomainPCIAddressGetNextSlot() a local static function
  qemu: replace calls to virDomainPCIAddressReserveNext*() with static
function
  qemu: set/use info->pciConnectFlags during
qemuDomainAssignDevicePCISlots
  qemu: set/use proper pciConnectFlags during hotplug
  qemu: assign virtio devices to PCIe slot when appropriate
  qemu: assign e1000e network devices to PCIe slots when appropriate
  qemu: assign nec-xhci (USB3) controller to a PCIe address when
appropriate
  qemu: only force an available legacy-PCI slot on domains with pci-root
  qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed
  qemu: don't force-add a dmi-to-pci-bridge just on principle
  qemu: add a USB3 controller to Q35 domains by default
  [RFC] qemu: try to put ich9 sound device at 00:1B.0

 src/conf/device_conf.h |   5 +
 src/conf/domain_addr.c | 180 -
 src/conf/domain_addr.h |  15 +-
 src/libvirt_private.syms   |   2 +-
 src/qemu/qemu_domain.c |  50 +-
 src/qemu/qemu_domain.h |   2 +
 src/qemu/qemu_domain_address.c | 802 +++--
 src/qemu/qemu_domain_address.h |   4 +
 src/qemu/qemu_hotplug.c|  25 +-
 tests/qemuxml2argvdata/qemuxml2argv-autoindex.args |  10 +-
 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args |   3 +-
 .../qemuxml2argv-q35-default-devices-only.args |  22 +
 

[libvirt] [PATCH v3 06/18] qemu: use virDomainPCIAddressReserveNextAddr in qemuDomainAssignDevicePCISlots

[Laine Stump]

instead of calling virDomainPCIAddressGetNextSlot() (which I want to
turn into a local static in domain_addr.c).
---
 src/qemu/qemu_domain_address.c | 31 +--
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 7f86c32..5a19f0b 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1256,7 +1256,6 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 {
 size_t i, j;
 virDomainPCIConnectFlags flags = 0; /* initialize to quiet gcc warning */
-virPCIDeviceAddress tmp_addr;
 
 /* PCI controllers */
 for (i = 0; i < def->ncontrollers; i++) {
@@ -1360,7 +1359,6 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 virPCIDeviceAddress addr = {0};
 bool foundAddr = false;
 
-memset(_addr, 0, sizeof(tmp_addr));
 for (j = 0; j < def->ncontrollers; j++) {
 if (IS_USB2_CONTROLLER(def->controllers[j]) &&
 def->controllers[j]->idx == cont->idx &&
@@ -1390,26 +1388,23 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 break;
 }
 
-if (!foundAddr) {
-/* This is the first part of the controller, so need
- * to find a free slot & then reserve a function */
-if (virDomainPCIAddressGetNextSlot(addrs, _addr, flags) < 
0)
+if (foundAddr) {
+/* Reserve this function on the slot we found */
+if (virDomainPCIAddressReserveAddr(addrs, , flags,
+   false, true) < 0)
 goto error;
 
-addr.bus = tmp_addr.bus;
-addr.slot = tmp_addr.slot;
+cont->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
+cont->info.addr.pci = addr;
+} else {
+/* This is the first part of the controller, so need
+ * to find a free slot & then reserve this function */
+if (virDomainPCIAddressReserveNextAddr(addrs, >info, 
flags,
+   addr.function, false) < 
0)
+goto error;
 
-addrs->lastaddr = addr;
-addrs->lastaddr.function = 0;
-addrs->lastaddr.multi = VIR_TRISTATE_SWITCH_ABSENT;
+cont->info.addr.pci.multi = addr.multi;
 }
-/* Finally we can reserve the slot+function */
-if (virDomainPCIAddressReserveAddr(addrs, , flags,
-   false, foundAddr) < 0)
-goto error;
-
-cont->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
-cont->info.addr.pci = addr;
 } else {
 if (virDomainPCIAddressReserveNextSlot(addrs, >info, flags) 
< 0)
 goto error;
-- 
2.7.4

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

Re: [libvirt] [PATCH v3 4/5] qmp: Add runnability information to query-cpu-definitions

[Eduardo Habkost]

On Tue, Sep 20, 2016 at 01:25:06PM -0500, Eric Blake wrote:
> On 09/19/2016 02:42 PM, Eduardo Habkost wrote:
> > Add a new optional field to query-cpu-definitions schema:
> > "unavailable-features". It will contain a list of QOM properties
> > that prevent the CPU model from running in the current host.
> > 
> > Cc: David Hildenbrand 
> > Cc: Michael Mueller 
> > Cc: Christian Borntraeger 
> > Cc: Cornelia Huck 
> > Cc: Jiri Denemark 
> > Cc: libvir-list@redhat.com
> > Signed-off-by: Eduardo Habkost 
> > ---
> 
> > +++ b/qapi-schema.json
> > @@ -3111,10 +3111,31 @@
> >  #  QEMU version, machine type, machine options and accelerator 
> > options.
> >  #  A static model is always migration-safe. (since 2.8)
> >  #
> > +# @unavailable-features: #optional List of properties that prevent
> > +#the CPU model from running in the current
> > +#host. (since 2.7)
> 
> We've missed 2.7; this should probably be 2.8.  Otherwise reads okay to me;
> 
> Reviewed-by: Eric Blake 

Oops! I will fix it before merging. Thanks for spotting!

-- 
Eduardo

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

[libvirt] [PATCH] config-post.h:fix a typo

[Nitesh Konkar]

Signed-off-by: Nitesh Konkar 
---
 config-post.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config-post.h b/config-post.h
index dd69197..6eb63db 100644
--- a/config-post.h
+++ b/config-post.h
@@ -20,7 +20,7 @@
  * Since virt-login-shell will be setuid, we must do everything
  * we can to avoid linking to other libraries. Many of them do
  * unsafe things in functions marked __atttribute__((constructor)).
- * The only way avoid to avoid such deps is to re-compile the
+ * The only way to avoid such deps is to re-compile the
  * functions with the code in question disabled, and for that we
  * must override the main config.h rules. Hence this file :-(
  */
-- 
2.1.0

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

Re: [libvirt] [PATCH v3 4/5] qmp: Add runnability information to query-cpu-definitions

[Eric Blake]

On 09/19/2016 02:42 PM, Eduardo Habkost wrote:
> Add a new optional field to query-cpu-definitions schema:
> "unavailable-features". It will contain a list of QOM properties
> that prevent the CPU model from running in the current host.
> 
> Cc: David Hildenbrand 
> Cc: Michael Mueller 
> Cc: Christian Borntraeger 
> Cc: Cornelia Huck 
> Cc: Jiri Denemark 
> Cc: libvir-list@redhat.com
> Signed-off-by: Eduardo Habkost 
> ---

> +++ b/qapi-schema.json
> @@ -3111,10 +3111,31 @@
>  #  QEMU version, machine type, machine options and accelerator 
> options.
>  #  A static model is always migration-safe. (since 2.8)
>  #
> +# @unavailable-features: #optional List of properties that prevent
> +#the CPU model from running in the current
> +#host. (since 2.7)

We've missed 2.7; this should probably be 2.8.  Otherwise reads okay to me;

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

Re: [libvirt] [PATCH v1 1/4] conf: add xen type for channels

[Joao Martins]

On 09/19/2016 11:29 PM, Jim Fehlig wrote:
> On 09/16/2016 05:43 PM, Joao Martins wrote:
>> So far only guestfwd and virtio were supported. Add an additional
>> for Xen as libxl channels create Xen console visible to the guest.
>>
>> Signed-off-by: Joao Martins 
>> ---
>>  docs/schemas/domaincommon.rng | 11 +++
>>  src/conf/domain_conf.c| 18 ++
>>  src/conf/domain_conf.h|  1 +
>>  src/qemu/qemu_command.c   |  1 +
>>  4 files changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
>> index 8aaa67e..5901452 100644
>> --- a/docs/schemas/domaincommon.rng
>> +++ b/docs/schemas/domaincommon.rng
>> @@ -3686,6 +3686,16 @@
>>
>>  
>>
>> +  
>> +
>> +  
>> +xen
>> +  
>> +  
>> +
>> +  
>> +
>> +  
>>
>>  
>>
>> @@ -3694,6 +3704,7 @@
>>  
>>
>>
>> +  
>>  
>>  
>>
>> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>> index 0828041..196799d 100644
>> --- a/src/conf/domain_conf.c
>> +++ b/src/conf/domain_conf.c
>> @@ -434,7 +434,8 @@ VIR_ENUM_IMPL(virDomainChrChannelTarget,
>>VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_LAST,
>>"none",
>>"guestfwd",
>> -  "virtio")
>> +  "virtio",
>> +  "xen")
>>  
>>  VIR_ENUM_IMPL(virDomainChrConsoleTarget,
>>VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST,
>> @@ -2068,6 +2069,7 @@ void virDomainChrDefFree(virDomainChrDefPtr def)
>>  VIR_FREE(def->target.addr);
>>  break;
>>  
>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>>  case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO:
>>  VIR_FREE(def->target.name);
>>  break;
>> @@ -9877,10 +9879,12 @@ virDomainChrDefParseTargetXML(virDomainChrDefPtr def,
>>  virSocketAddrSetPort(def->target.addr, port);
>>  break;
>>  
>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>>  case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO:
>>  def->target.name = virXMLPropString(cur, "name");
>>  
>> -if (!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) &&
>> +if (def->targetType == 
>> VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO &&
>> +!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) &&
>>  (stateStr = virXMLPropString(cur, "state"))) {
>>  int tmp;
> 
> I guess we'll need an answer to your question about the 'state' attribute to
> know if this is needed.
Based in the earlier discussion with Michal I guess this can stay as it is?

>> @@ -10171,7 +10175,8 @@ 
>> virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def,
>>  /* path can be auto generated */
>>  if (!path &&
>>  (!chr_def ||
>> - chr_def->targetType != 
>> VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO)) {
>> + (chr_def->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN 
>> &&
>> +  chr_def->targetType != 
>> VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO))) {
>>  virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
>> _("Missing source path attribute for char 
>> device"));
>>  goto error;
>> @@ -14373,6 +14378,7 @@ virDomainChrEquals(virDomainChrDefPtr src,
>>  if (src->targetType != tgt->targetType)
>>  return false;
>>  switch ((virDomainChrChannelTargetType) src->targetType) {
>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>>  case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO:
>>  return STREQ_NULLABLE(src->target.name, tgt->target.name);
>>  break;
>> @@ -18310,6 +18316,8 @@ 
>> virDomainChannelDefCheckABIStability(virDomainChrDefPtr src,
>>  }
>>  
>>  switch (src->targetType) {
>> +
>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>>  case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO:
>>  if (STRNEQ_NULLABLE(src->target.name, dst->target.name)) {
>>  virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
>> @@ -21432,11 +21440,13 @@ virDomainChrDefFormat(virBufferPtr buf,
>>  break;
>>  }
>>  
>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>>  case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO:
>>  if (def->target.name)
>>  virBufferEscapeString(buf, " name='%s'", def->target.name);
>>  
>> -if (def->state != VIR_DOMAIN_CHR_DEVICE_STATE_DEFAULT &&
>> +if (def->targetType == 
>> VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO &&
>> +def->state != VIR_DOMAIN_CHR_DEVICE_STATE_DEFAULT &&
>>  !(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE)) {
>>  virBufferAsprintf(buf, " state='%s'",
>>
>> 

Re: [libvirt] [PATCH v1 3/4] xenconfig: channels conversion support

[Joao Martins]

On 09/20/2016 04:04 AM, Jim Fehlig wrote:
> On 09/16/2016 05:43 PM, Joao Martins wrote:
>> Add support for formating/parsing libxl channels.
>>
>> Syntax on xen libxl goes as following:
>> channel=["connection=pty|socket,path=/path/to/socket,name=XXX",...]
>>
>> Signed-off-by: Joao Martins 
>> ---
>>  src/xenconfig/xen_xl.c | 176 
>> +
>>  1 file changed, 176 insertions(+)
>>
>> diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
>> index 7774dfc..eea24b9 100644
>> --- a/src/xenconfig/xen_xl.c
>> +++ b/src/xenconfig/xen_xl.c
>> @@ -685,6 +685,93 @@ xenParseXLUSB(virConfPtr conf, virDomainDefPtr def)
>>  return 0;
>>  }
>>  
>> +static int
>> +xenParseXLChannel(virConfPtr conf, virDomainDefPtr def)
>> +{
>> +virConfValuePtr list = virConfGetValue(conf, "channel");
>> +virDomainChrDefPtr channel = NULL;
>> +char *name = NULL;
>> +char *path = NULL;
>> +
>> +if (list && list->type == VIR_CONF_LIST) {
>> +list = list->list;
>> +while (list) {
>> +char type[10];
>> +char *key;
>> +
>> +if ((list->type != VIR_CONF_STRING) || (list->str == NULL))
>> +goto skipchannel;
>> +
>> +key = list->str;
>> +while (key) {
>> +char *data;
>> +char *nextkey = strchr(key, ',');
>> +
>> +if (!(data = strchr(key, '=')))
>> +goto skipchannel;
>> +data++;
>> +
>> +if (STRPREFIX(key, "connection=")) {
>> +int len = nextkey ? (nextkey - data) : sizeof(type) - 1;
>> +if (virStrncpy(type, data, len, sizeof(type)) == NULL) {
>> +virReportError(VIR_ERR_INTERNAL_ERROR,
>> +   _("connection %s too big"), data);
>> +goto skipchannel;
>> +}
>> +} else if (STRPREFIX(key, "name=")) {
>> +int len = nextkey ? (nextkey - data) : strlen(data);
>> +VIR_FREE(name);
>> +if (VIR_STRNDUP(name, data, len) < 0)
>> +goto cleanup;
>> +} else if (STRPREFIX(key, "path=")) {
>> +int len = nextkey ? (nextkey - data) : strlen(data);
>> +VIR_FREE(path);
>> +if (VIR_STRNDUP(path, data, len) < 0)
>> +goto cleanup;
>> +}
>> +
>> +while (nextkey && (nextkey[0] == ',' ||
>> +   nextkey[0] == ' ' ||
>> +   nextkey[0] == '\t'))
>> +nextkey++;
>> +key = nextkey;
>> +}
>> +
>> +if (!(channel = virDomainChrDefNew()))
>> +goto cleanup;
>> +
>> +if (STRPREFIX(type, "socket")) {
>> +channel->source.type = VIR_DOMAIN_CHR_TYPE_UNIX;
>> +channel->source.data.nix.path = path;
>> +channel->source.data.nix.listen = 1;
>> +} else if (STRPREFIX(type, "pty")) {
>> +channel->source.type = VIR_DOMAIN_CHR_TYPE_PTY;
>> +VIR_FREE(path);
>> +} else {
>> +goto cleanup;
>> +}
>> +
>> +channel->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL;
>> +channel->targetType = VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN;
>> +channel->target.name = name;
>> +
>> +if (VIR_APPEND_ELEMENT(def->channels, def->nchannels, channel) 
>> < 0)
>> +goto cleanup;
>> +
>> +skipchannel:
>> +list = list->next;
>> +}
>> +}
>> +
>> +return 0;
>> +
>> + cleanup:
>> +virDomainChrDefFree(channel);
>> +VIR_FREE(path);
>> +VIR_FREE(name);
>> +return -1;
>> +}
>> +
>>  virDomainDefPtr
>>  xenParseXL(virConfPtr conf,
>> virCapsPtr caps,
>> @@ -720,6 +807,9 @@ xenParseXL(virConfPtr conf,
>>  if (xenParseXLUSBController(conf, def) < 0)
>>  goto cleanup;
>>  
>> +if (xenParseXLChannel(conf, def) < 0)
>> +goto cleanup;
>> +
>>  if (virDomainDefPostParse(def, caps, VIR_DOMAIN_DEF_PARSE_ABI_UPDATE,
>>xmlopt) < 0)
>>  goto cleanup;
>> @@ -1347,6 +1437,89 @@ xenFormatXLUSB(virConfPtr conf,
>>  return -1;
>>  }
>>  
>> +static int
>> +xenFormatXLChannel(virConfValuePtr list, virDomainChrDefPtr channel)
>> +{
>> +virBuffer buf = VIR_BUFFER_INITIALIZER;
>> +int sourceType = channel->source.type;
>> +virConfValuePtr val, tmp;
>> +
>> +/* connection */
>> +virBufferAddLit(, "connection=");
>> +switch (sourceType) {
>> +case VIR_DOMAIN_CHR_TYPE_PTY:
>> +virBufferAddLit(, "pty,");
>> +break;
>> +case VIR_DOMAIN_CHR_TYPE_UNIX:
>> +

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Paolo Bonzini]

On 20/09/2016 17:14, Daniel P. Berrange wrote:
> Any VM which
> uses the separate namespace is tainted, which means if theres a bug
> report we'll require the reported to remove whatever config caused
> the tainting and then reproduce the problem.
> 
> If the vendor specific mdev parameters are things that apps will often
> need to be able to set, then allowing it via a separate namespace is
> just providing a backdoor that everyone needs to use, defeating the
> point of using a separate namespace.

No, they don't need to be often set, and tainting the domain is a good idea.

Paolo

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Alex Williamson]

On Tue, 20 Sep 2016 21:53:16 +0530
Kirti Wankhede  wrote:

> On 9/20/2016 8:13 PM, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 19:51:58 +0530
> > Kirti Wankhede  wrote:
> >   
> >> On 9/20/2016 3:06 AM, Alex Williamson wrote:  
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede  wrote:
> >>> 
>  Hi libvirt experts,
> 
> 
>  'create':
>  Write-only file. Mandatory.
>  Accepts string to create mediated device.
> 
>  'name':
>  Read-Only file. Mandatory.
>  Returns string, the name of that type id.
> 
>  'fb_length':
>  Read-only file. Mandatory.
>  Returns {K,M,G}, size of framebuffer.
> >>>
> >>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> >>> just one user of mediated devices.
> >>> 
> >>
> >> As per our discussion in BOF, we would define class and its attributes.
> >> As I mentioned above these are attributes of "display" class.  
> > 
> > Just as I didn't know here, how does libvirt know the class of a given
> > type id?
> >
> 
> Yes, we need some way to identify the class as Daniel mentioned in his
> suggestion. Add a file 'class' in mdev_supported_types that would return
> the class.
> 
> 
> >>>  Can all parameters be changed dynamically?
> >>
> >> Parameters here would be extra parameters which are not listed above in
> >> mandatory list. If such parameters are required to set, these parameters
> >> should be set per mdev device before VM is booted.
> >>  
> >>>  Do parameter changes apply to existing devices or only future devices?   
> >>>  
> >>
> >> No, it should be applied at the time when mdev device is created or
> >> after mdev device is created but before VM is booted. It will not be
> >> applicable to existing devices.
> >>  
> >>>  This is a poorly specified
> >>> interface.  I'd prefer this be done via module options on the vendor
> >>> driver.
> >>> 
> >>
> >> Module option is not suitable here, in that case such parameters would
> >> be applied to all mdev device created for vendor driver and that is not
> >> what we want to.  
> > 
> > Then use attributes on the mdev device itself, this is not an
> > acceptable interface.
> >   
> 
>  With above example, vGPU device XML would look like:
> 
> 
>   my-vgpu
>   pci__86_00_0
>   
> 
> 1
> 'frame_rate_limiter=0'
>   
> 
> 
>  'type id' is mandatory.
> >>>
> >>> I was under the impression that the vendor supplied "name" was the one
> >>> unique identifier.  We're certainly not going to create a registrar to
> >>> hand out type ids to each vendor, so what makes type id unique?
> >>
> >> Type id is unique, 'name' is the name (string) of device that would be
> >> displayed in guest OS for that type of mdev device.  
> > 
> > We were told at the BoF that name was the unique string which would be
> > consistent and you again indicate below that "GRID-M60-0B" has a fixed
> > set of attributes, so why do we care what type id is associated with
> > that name?
> >
> >>>  I have
> >>> a hard time believing that a given vendor can even allocate unique type
> >>> ids for their own devices.  Unique type id across vendors is not
> >>> practical.  So which attribute are we actually using to identify which
> >>> type of mdev device we need and why would we ever specify additional
> >>> attributes like fb_length?  Doesn't the vendor guarantee that "GRID
> >>> M60-0B" has a fixed setup of those attributes?
> >>> 
> >>
> >> Specifying attributes here is not our requirement. Yes we have fixed set
> >> of attributes for "GRID-M60-0B" and on.
> >> We are defining the attributed here for "display" class for all other
> >> vendor of gpu can use.
> >>
> >>  
>  'group' is optional. It should be a unique number in the system among
>  all the groups created for mdev devices. Its usage is:
>    - not needed if single vGPU device is being assigned to a domain.
>    - only need to be set if multiple vGPUs need to be assigned to a
>  domain and vendor driver have 'requires_group' file in type id directory.
>    - if type id directory include 'requires_group' and user tries to
>  assign multiple vGPUs to a domain without having  field in XML,
>  it will create single vGPU.
> >>>
> >>> We never finished our discussion of how this gets implemented or
> >>> whether a group applies only to devices from the same vendor, same
> >>> device, how heterogeneous groups are handled, etc.
> >>> 
> >>
> >> We agreed on above points that I mentioned here and we wish to know what
> >> libvirt folks think, right?
> >> Since there were no inputs on that thread I thought I should summarize
> >> what had been discussed and get libvirt experts thoughts on this.  
> > 
> > No, that was just an idea that was never full 

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
> 
> 
> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > As I've said in my earlier reply - libvirt will *NOT* support passing
> > arbitrary vendor specific parameters as a blob via the XML. Everything
> > that appears in the XML must be *fully* specified and explicitly
> > represented in the XML  as a distinct attribute or element.
> 
>  Are generic key/value attributes (e.g. a  element) acceptable?
> >>>
> >>> Only if libvirt has a known list of valid attribute key names upfront.
> >>> We don't want to just blindly expose arbitary vendor specific keys exposed
> >>> by the kernel. Libvirt's job is to ensure the XML representation is vendor
> >>> portable
> >>
> 
> In key/value attributes (taking example from proposed xml file)
> 
> 2560x1600
> 
> 'Key' (i.e. 'resolution') should be known upfront, not the value, right?

NB, resolution is a good example of why we would *not* use the
generic $value format in
the XML. Instead we'd represent it as

   

as applications should not have to further parse data after extracting
it from an XML attribute/element.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 10:12:20PM +0530, Kirti Wankhede wrote:
> 
> 
> On 9/20/2016 10:06 PM, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
> >>
> >>
> >> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> >>> On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> 
> 
>  On 20/09/2016 16:58, Daniel P. Berrange wrote:
> >>> As I've said in my earlier reply - libvirt will *NOT* support passing
> >>> arbitrary vendor specific parameters as a blob via the XML. Everything
> >>> that appears in the XML must be *fully* specified and explicitly
> >>> represented in the XML  as a distinct attribute or element.
> >>
> >> Are generic key/value attributes (e.g. a  element) 
> >> acceptable?
> >
> > Only if libvirt has a known list of valid attribute key names upfront.
> > We don't want to just blindly expose arbitary vendor specific keys 
> > exposed
> > by the kernel. Libvirt's job is to ensure the XML representation is 
> > vendor
> > portable
> 
> >>
> >> In key/value attributes (taking example from proposed xml file)
> >>
> >> 2560x1600
> >>
> >> 'Key' (i.e. 'resolution') should be known upfront, not the value, right?
> > 
> > Yes, the actual value is not important - only its structured.
> > ie, libvirt would check that it is in the format '$WIDTHx$HEIGHT'
> > and reject it if not.
> > 
> 
> In this particular example, libvirt checks if its integer? or value
> could be 2560x1600 or 4096x4096 both are valid?
>
> Does libvirt accept string value?

Err, as I said, we'd validate that its in the format '$WIDTHx$HEIGHT'


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Kirti Wankhede]

On 9/20/2016 10:06 PM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
>>
>>
>> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
>>> On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:


 On 20/09/2016 16:58, Daniel P. Berrange wrote:
>>> As I've said in my earlier reply - libvirt will *NOT* support passing
>>> arbitrary vendor specific parameters as a blob via the XML. Everything
>>> that appears in the XML must be *fully* specified and explicitly
>>> represented in the XML  as a distinct attribute or element.
>>
>> Are generic key/value attributes (e.g. a  element) acceptable?
>
> Only if libvirt has a known list of valid attribute key names upfront.
> We don't want to just blindly expose arbitary vendor specific keys exposed
> by the kernel. Libvirt's job is to ensure the XML representation is vendor
> portable

>>
>> In key/value attributes (taking example from proposed xml file)
>>
>> 2560x1600
>>
>> 'Key' (i.e. 'resolution') should be known upfront, not the value, right?
> 
> Yes, the actual value is not important - only its structured.
> ie, libvirt would check that it is in the format '$WIDTHx$HEIGHT'
> and reject it if not.
> 

In this particular example, libvirt checks if its integer? or value
could be 2560x1600 or 4096x4096 both are valid?

Does libvirt accept string value?

Kirti

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
> 
> 
> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > As I've said in my earlier reply - libvirt will *NOT* support passing
> > arbitrary vendor specific parameters as a blob via the XML. Everything
> > that appears in the XML must be *fully* specified and explicitly
> > represented in the XML  as a distinct attribute or element.
> 
>  Are generic key/value attributes (e.g. a  element) acceptable?
> >>>
> >>> Only if libvirt has a known list of valid attribute key names upfront.
> >>> We don't want to just blindly expose arbitary vendor specific keys exposed
> >>> by the kernel. Libvirt's job is to ensure the XML representation is vendor
> >>> portable
> >>
> 
> In key/value attributes (taking example from proposed xml file)
> 
> 2560x1600
> 
> 'Key' (i.e. 'resolution') should be known upfront, not the value, right?

Yes, the actual value is not important - only its structured.
ie, libvirt would check that it is in the format '$WIDTHx$HEIGHT'
and reject it if not.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Kirti Wankhede]

On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> As I've said in my earlier reply - libvirt will *NOT* support passing
> arbitrary vendor specific parameters as a blob via the XML. Everything
> that appears in the XML must be *fully* specified and explicitly
> represented in the XML  as a distinct attribute or element.

 Are generic key/value attributes (e.g. a  element) acceptable?
>>>
>>> Only if libvirt has a known list of valid attribute key names upfront.
>>> We don't want to just blindly expose arbitary vendor specific keys exposed
>>> by the kernel. Libvirt's job is to ensure the XML representation is vendor
>>> portable
>>

In key/value attributes (taking example from proposed xml file)

2560x1600

'Key' (i.e. 'resolution') should be known upfront, not the value, right?

Kirti


>> Ok, then I guess vendor-specific mdev parameters are out completely.  Or
>> could they be added under a separate namespace, like QEMU passthrough?
> 
> The QEMU XML namespace that allows passthrough is intended either as a
> short term hack to let people experiment with new QEMU features, before
> they get explicitly represented in the main XML namespace, or in a few
> cases, for things we never want to support officially.  Any VM which
> uses the separate namespace is tainted, which means if theres a bug
> report we'll require the reported to remove whatever config caused
> the tainting and then reproduce the problem.
> 
> If the vendor specific mdev parameters are things that apps will often
> need to be able to set, then allowing it via a separate namespace is
> just providing a backdoor that everyone needs to use, defeating the
> point of using a separate namespace.
> 
> We don't want to knowingly design a system which defacto requires
> the app to use the separate namespace most/all of the time.
> 
> 
> Regards,
> Daniel
> 

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Kirti Wankhede]

On 9/20/2016 8:13 PM, Alex Williamson wrote:
> On Tue, 20 Sep 2016 19:51:58 +0530
> Kirti Wankhede  wrote:
> 
>> On 9/20/2016 3:06 AM, Alex Williamson wrote:
>>> On Tue, 20 Sep 2016 02:05:52 +0530
>>> Kirti Wankhede  wrote:
>>>   
 Hi libvirt experts,


 'create':
 Write-only file. Mandatory.
 Accepts string to create mediated device.

 'name':
 Read-Only file. Mandatory.
 Returns string, the name of that type id.

 'fb_length':
 Read-only file. Mandatory.
 Returns {K,M,G}, size of framebuffer.  
>>>
>>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
>>> just one user of mediated devices.
>>>   
>>
>> As per our discussion in BOF, we would define class and its attributes.
>> As I mentioned above these are attributes of "display" class.
> 
> Just as I didn't know here, how does libvirt know the class of a given
> type id?
>  

Yes, we need some way to identify the class as Daniel mentioned in his
suggestion. Add a file 'class' in mdev_supported_types that would return
the class.


>>>  Can all parameters be changed dynamically?  
>>
>> Parameters here would be extra parameters which are not listed above in
>> mandatory list. If such parameters are required to set, these parameters
>> should be set per mdev device before VM is booted.
>>
>>>  Do parameter changes apply to existing devices or only future devices?  
>>
>> No, it should be applied at the time when mdev device is created or
>> after mdev device is created but before VM is booted. It will not be
>> applicable to existing devices.
>>
>>>  This is a poorly specified
>>> interface.  I'd prefer this be done via module options on the vendor
>>> driver.
>>>   
>>
>> Module option is not suitable here, in that case such parameters would
>> be applied to all mdev device created for vendor driver and that is not
>> what we want to.
> 
> Then use attributes on the mdev device itself, this is not an
> acceptable interface.
> 

 With above example, vGPU device XML would look like:


  my-vgpu
  pci__86_00_0
  

1
'frame_rate_limiter=0'
  


 'type id' is mandatory.  
>>>
>>> I was under the impression that the vendor supplied "name" was the one
>>> unique identifier.  We're certainly not going to create a registrar to
>>> hand out type ids to each vendor, so what makes type id unique?  
>>
>> Type id is unique, 'name' is the name (string) of device that would be
>> displayed in guest OS for that type of mdev device.
> 
> We were told at the BoF that name was the unique string which would be
> consistent and you again indicate below that "GRID-M60-0B" has a fixed
> set of attributes, so why do we care what type id is associated with
> that name?
>  
>>>  I have
>>> a hard time believing that a given vendor can even allocate unique type
>>> ids for their own devices.  Unique type id across vendors is not
>>> practical.  So which attribute are we actually using to identify which
>>> type of mdev device we need and why would we ever specify additional
>>> attributes like fb_length?  Doesn't the vendor guarantee that "GRID
>>> M60-0B" has a fixed setup of those attributes?
>>>   
>>
>> Specifying attributes here is not our requirement. Yes we have fixed set
>> of attributes for "GRID-M60-0B" and on.
>> We are defining the attributed here for "display" class for all other
>> vendor of gpu can use.
>>
>>
 'group' is optional. It should be a unique number in the system among
 all the groups created for mdev devices. Its usage is:
   - not needed if single vGPU device is being assigned to a domain.
   - only need to be set if multiple vGPUs need to be assigned to a
 domain and vendor driver have 'requires_group' file in type id directory.
   - if type id directory include 'requires_group' and user tries to
 assign multiple vGPUs to a domain without having  field in XML,
 it will create single vGPU.  
>>>
>>> We never finished our discussion of how this gets implemented or
>>> whether a group applies only to devices from the same vendor, same
>>> device, how heterogeneous groups are handled, etc.
>>>   
>>
>> We agreed on above points that I mentioned here and we wish to know what
>> libvirt folks think, right?
>> Since there were no inputs on that thread I thought I should summarize
>> what had been discussed and get libvirt experts thoughts on this.
> 
> No, that was just an idea that was never full defined.  We had that
> idea, the IOMMU group idea, the invalid container idea...  This is
> still an open question in the design.
> 

We do want to close down on the design as soon as possible.
I had tried to address open questions in earlier discussion also. Let me
address your concerns you have:

> whether a group applies only to devices from the same vendor,

Yes.

> same device,

Re: [libvirt] [PATCH v2] qemu-migration: Disallow migration of read only disk

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 05:49:17PM +0200, Peter Krempa wrote:
> On Tue, Sep 20, 2016 at 15:21:16 +0100, Daniel Berrange wrote:
> > On Tue, Sep 20, 2016 at 03:53:16PM +0200, Peter Krempa wrote:
> > > On Tue, Sep 20, 2016 at 09:40:22 -0400, Corey S. McQuay wrote:
> > > > Currently Libvirt allows attempts to migrate read only disks. Qemu 
> > > > cannot handle this as read only
> > > > disks cannot be written to on the destination system. The end result is 
> > > > a cryptic error message
> > > > and a failed migration.
> > > 
> > > This is not necessarily true. Read only disks can sometimes be in fact
> > > backed by storage that is writable and it's desired to be migrated.
> > 
> > If 'def->readonly' is true, then the security drivers won't allow
> > QEMU to write to the image, regardless of whether the underlying
> > storage is writable.
> 
> That definitely would be just a bug in the implementation rather than a
> reason to do this.

That's not a bug - that's a feature - if the disk is marked readonly,
SELinux is right to prevent QEMU writing to the disk.

> In fact the problem is that qemu itself forbids to write the data to a
> readonly marked block backend, which indeed makes this impossible
> although I'm pretty certain that it worked for me in some configuration.

That's a further layer of protection/complication, but I'm concerned
primarily about fact that libvirt is intentionally blocking writes

> At any rate, checking this on the source of migration is incorrect. The
> destination should do such check if there's currently no way to persuade
> qemu do do it. We still may later find a way and all hosts running older
> versions would be hosed.

So the check would belong in qemuMigrationStartNBDServer, rather than
in the DriveMirror method


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [RFC PATCH] Use disable-modern=on for disk device='lun'

[Laine Stump]

On 09/20/2016 08:57 AM, Daniel P. Berrange wrote:

On Tue, Sep 20, 2016 at 02:21:49PM +0200, Ján Tomko wrote:

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

For virtio-blk, scsi=on has been deprecated in virtio-1,
so  no longer works with
with a virtio-blk-pci device with machine types newer than 2.7:
https://bugzilla.redhat.com/show_bug.cgi?id=1245453
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9a4c0e22

Add disable-modern=on on the QEMU command line to prolong
the suffering for a while longer.
---
The alternative would be using the QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY
capability to report an error, instead of waiting until QEMU fails with
an error, since it's the first commit when the following error should
be reachable via libvirt-generated command line:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=efb8206c

My preference would be for us to come to some conclusion of the
way we will represent disable-modern/disable-legacy in the
XML before we try to fix this device=lun problem.


Another open question is whether or not this is a problem if you start 
an existing domain that uses a pre-virtio-1.0 machinetype but you're 
using a qemu binary that does have virtio-1.0. I'm guessing that it 
should work with no extra "disable-modern=on" required (that's the whole 
point of versioned machinetypes after all). If so, then existing configs 
will continue to work properly with no change, and for new configs that 
use virtio-1.0-capable machinetypes maybe it will be more merciful to 
immediately complain when somebody tries to use device='lun', thus 
forcing people who want the "lun" functionality to switch to virtio-scsi 
right away, rather than propagating its use with virtio-blk-pci even 
further into the future (which of course will lead to it living *forever*).


Trying to restate it more clearly: the problem is that the only way for 
libvirt to detect whether or not qemu is going to fail is by querying 
for presence of virtio-1.0 (which we do indirectly by looking for 
"disable-legacy" in the options), and that only tells us whether or not 
the qemu binary supports it, *not* whether a particular machinetype 
supported by the qemu binary supports it. The same binary might support 
several machinetypes that support virtio-1.0 (and thus don't support 
device='lun' without adding in disable-modern=on) and several 
machinetypes that *don't* support virtio-1.0 (and thus should have no 
problem with device='lun'), and libvirt has no way of knowing which is 
which, so libvirt *can't* be the one to complain about this, or even to 
automatically add the "disable-modern=on" (what happens if you add 
"disable-modern=on" to the virtio-blk-pci device of a machinetype that 
is too old for virtio-1.0? Is it ignored? Or does qemu give an error and 
exit? I haven't tried it, so don't know).


In the end, until qemu provides us with a way to query capabilities *per 
machinetype*, there's realistically nothing libvirt can do about this 
problem that isn't going to be wrong for somebody. (Hi Eduardo!! :-)


TL;DR - I've actually come to the opinion that the only right thing for 
libvirt to do here is "nothing" (unless you want to write code to try 
and interpret the qemu error message after the fact Ew, never 
mind, scrap that!)



In general I'm not a fan of silently changing configs behind
the users back. IOW, if we have XML for setting disable-modern
explicitly, then I would not want to see us silently setting
disable-modern ourselves. Leave it upto the app to decide to
set it if they really want to continue using virtio-blk instead
of virtio-scsi.


  src/qemu/qemu_command.c| 12 +
  .../qemuxml2argv-virtio-lun-legacy.args| 30 +
  .../qemuxml2argv-virtio-lun-legacy.xml | 52 ++
  tests/qemuxml2argvtest.c   |  3 ++
  4 files changed, 97 insertions(+)
  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-lun-legacy.args
  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-lun-legacy.xml

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 051a0bc..03dc20e 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -2075,6 +2075,18 @@ qemuBuildDriveDevStr(const virDomainDef *def,
  virBufferAddLit(, "virtio-blk-pci");
  if (disk->iothread)
  virBufferAsprintf(, ",iothread=iothread%u", 
disk->iothread);
+
+/*
+ * SCSI command passthrough was deprecated in virtio 1.0,
+ * see https://bugzilla.redhat.com/show_bug.cgi?id=1365823
+ */
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SCSI) &&
+disk->device == VIR_DOMAIN_DISK_DEVICE_LUN &&
+virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY)) 
{
+VIR_WARN("lun type devices are deprecated for virtio-blk-pci 
devices, "
+ 

Re: [libvirt] [PATCH v2] qemu-migration: Disallow migration of read only disk

[Peter Krempa]

On Tue, Sep 20, 2016 at 15:21:16 +0100, Daniel Berrange wrote:
> On Tue, Sep 20, 2016 at 03:53:16PM +0200, Peter Krempa wrote:
> > On Tue, Sep 20, 2016 at 09:40:22 -0400, Corey S. McQuay wrote:
> > > Currently Libvirt allows attempts to migrate read only disks. Qemu cannot 
> > > handle this as read only
> > > disks cannot be written to on the destination system. The end result is a 
> > > cryptic error message
> > > and a failed migration.
> > 
> > This is not necessarily true. Read only disks can sometimes be in fact
> > backed by storage that is writable and it's desired to be migrated.
> 
> If 'def->readonly' is true, then the security drivers won't allow
> QEMU to write to the image, regardless of whether the underlying
> storage is writable.

That definitely would be just a bug in the implementation rather than a
reason to do this.

In fact the problem is that qemu itself forbids to write the data to a
readonly marked block backend, which indeed makes this impossible
although I'm pretty certain that it worked for me in some configuration.

At any rate, checking this on the source of migration is incorrect. The
destination should do such check if there's currently no way to persuade
qemu do do it. We still may later find a way and all hosts running older
versions would be hosed.

Peter

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> 
> 
> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > > > As I've said in my earlier reply - libvirt will *NOT* support passing
> > > > arbitrary vendor specific parameters as a blob via the XML. Everything
> > > > that appears in the XML must be *fully* specified and explicitly
> > > > represented in the XML  as a distinct attribute or element.
> > > 
> > > Are generic key/value attributes (e.g. a  element) acceptable?
> >
> > Only if libvirt has a known list of valid attribute key names upfront.
> > We don't want to just blindly expose arbitary vendor specific keys exposed
> > by the kernel. Libvirt's job is to ensure the XML representation is vendor
> > portable
> 
> Ok, then I guess vendor-specific mdev parameters are out completely.  Or
> could they be added under a separate namespace, like QEMU passthrough?

The QEMU XML namespace that allows passthrough is intended either as a
short term hack to let people experiment with new QEMU features, before
they get explicitly represented in the main XML namespace, or in a few
cases, for things we never want to support officially.  Any VM which
uses the separate namespace is tainted, which means if theres a bug
report we'll require the reported to remove whatever config caused
the tainting and then reproduce the problem.

If the vendor specific mdev parameters are things that apps will often
need to be able to set, then allowing it via a separate namespace is
just providing a backdoor that everyone needs to use, defeating the
point of using a separate namespace.

We don't want to knowingly design a system which defacto requires
the app to use the separate namespace most/all of the time.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [PATCH v7 2/5] conf: Introduce {default|chardev}_tls_x509_secret_uuid

[John Ferlan]

On 09/20/2016 08:52 AM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 08:26:55AM -0400, John Ferlan wrote:
>>
>>
>> On 09/19/2016 10:53 AM, Daniel P. Berrange wrote:
>>> On Mon, Sep 19, 2016 at 10:39:21AM -0400, John Ferlan wrote:
 Add a new qemu.conf variables to store the UUID for the secret that could
 be used to present credentials to access the TLS chardev.  Since this will
 be a server level and it's possible to use some sort of default, introduce
 both the default and chardev logic at the same time making the setting of
 the chardev check for it's own value, then if not present checking whether
 the default value had been set.

 The chardevTLSx509haveUUID bool will be used as the marker for whether
 the chardevTLSx509secretUUID was successfully read. In the future this
 is how it'd determined whether to add the secret object for a TLS object.

 Signed-off-by: John Ferlan 
 ---
  src/qemu/libvirtd_qemu.aug |  2 ++
  src/qemu/qemu.conf | 24 
  src/qemu/qemu_conf.c   | 22 ++
  src/qemu/qemu_conf.h   |  3 +++
  src/qemu/test_libvirtd_qemu.aug.in |  2 ++
  5 files changed, 53 insertions(+)

 diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
 index 988201e..73ebeda 100644
 --- a/src/qemu/libvirtd_qemu.aug
 +++ b/src/qemu/libvirtd_qemu.aug
 @@ -29,6 +29,7 @@ module Libvirtd_qemu =
 (* Config entry grouped by function - same order as example config *)
 let default_tls_entry = str_entry "default_tls_x509_cert_dir"
   | bool_entry "default_tls_x509_verify"
 + | str_entry "default_tls_x509_secret_uuid"
  
 let vnc_entry = str_entry "vnc_listen"
   | bool_entry "vnc_auto_unix_socket"
 @@ -51,6 +52,7 @@ module Libvirtd_qemu =
 let chardev_entry = bool_entry "chardev_tls"
   | str_entry "chardev_tls_x509_cert_dir"
   | bool_entry "chardev_tls_x509_verify"
 + | str_entry "chardev_tls_x509_secret_uuid"
  
 let nogfx_entry = bool_entry "nographics_allow_host_audio"
  
 diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
 index e4c2aae..7114fa1 100644
 --- a/src/qemu/qemu.conf
 +++ b/src/qemu/qemu.conf
 @@ -28,6 +28,20 @@
  #
  #default_tls_x509_verify = 1
  
 +#
 +# In order to provide a password to unlock the private key to be used
 +# in order to provide the TLS credentials, a libvirt secret will need
 +# to be created and then the UUID of that secret added as a configuration
 +# parameter. See the libvirt documentation for specific details regarding
 +# how to create a "tls" secret type.
 +#
 +# NB This default all-zeros UUID will not work. Replace it with the
 +# output from the UUID for the TLS secret from a 'virsh secret-list'
 +# command and then uncomment the entry
 +#
 +#default_tls_x509_secret_uuid = "----"
>>>
>>> We could perhaps be a little more explicit about the fact that when
>>> this is commented out, the private key is required to be in
>>> non-encrypted PEM format.
>>>
>>
>> Fair enough - a simple enough addition, so at the end of the first
>> paragraph (and repeated again for chardev_tls_x509_secret_uuid), how about:
>>
>> " A libvirt secret requires usage of a non-encrypted PEM format
>> certificate."
>>
>> Or is there some other wording that is preferable?
> 
> Something like this:
> 
>   "Libvirt assumes the server-key.pem file is unencrypted by default.
>To use an encrypted server-key.pem file, the password to decrypt
>the PEM file is requird. This can be provided by creating a secret
>object in libvirt and then uncommenting this setting to set the
>UUID of the secret"
> 

OK - I'll adjust this patch.

In terms of the others are they reasonable or is it more of the case
that the available hours needed to review exceed capacity...

Tks -

John

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Paolo Bonzini]

On 20/09/2016 16:58, Daniel P. Berrange wrote:
> > > As I've said in my earlier reply - libvirt will *NOT* support passing
> > > arbitrary vendor specific parameters as a blob via the XML. Everything
> > > that appears in the XML must be *fully* specified and explicitly
> > > represented in the XML  as a distinct attribute or element.
> > 
> > Are generic key/value attributes (e.g. a  element) acceptable?
>
> Only if libvirt has a known list of valid attribute key names upfront.
> We don't want to just blindly expose arbitary vendor specific keys exposed
> by the kernel. Libvirt's job is to ensure the XML representation is vendor
> portable

Ok, then I guess vendor-specific mdev parameters are out completely.  Or
could they be added under a separate namespace, like QEMU passthrough?

Paolo

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 04:49:09PM +0200, Paolo Bonzini wrote:
> 
> 
> On 20/09/2016 16:41, Daniel P. Berrange wrote:
> > As I've said in my earlier reply - libvirt will *NOT* support passing
> > arbitrary vendor specific parameters as a blob via the XML. Everything
> > that appears in the XML must be *fully* specified and explicitly
> > represented in the XML  as a distinct attribute or element.
> 
> Are generic key/value attributes (e.g. a  element) acceptable?

Only if libvirt has a known list of valid attribute key names upfront.
We don't want to just blindly expose arbitary vendor specific keys exposed
by the kernel. Libvirt's job is to ensure the XML representation is vendor
portable and stable across software versions. If we just blindly expose
the strings reported by the host, then the XML will change if the vendor
arbitararily renames an attribute in a software update, or if two
vendors have the same concept there's no guaranteed name between them.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [PATCH] qemuDomainOpenGraphics: Start job early

[Michal Privoznik]

On 20.09.2016 15:33, Jiri Denemark wrote:
> Checking if a domain's definition or if it is active before we got a job
> is pointless since the domain might have changed in the meantime.
> 
> Luckily libvirtd didn't crash when the API tried to talk to an inactive
> domain:
> 
> debug : qemuDomainObjBeginJobInternal:2914 : Started job: modify
> (async=none vm=0x7f8f340140c0 name=ble)
> debug : qemuDomainObjEnterMonitorInternal:3137 : Entering monitor
> (mon=(nil) vm=0x7f8f340140c0 name=ble)
> warning : virObjectLock:319 : Object (nil) ((unknown)) is not a
> virObjectLockable instance
> debug : qemuMonitorOpenGraphics:3505 : protocol=spice fd=27
> fdname=graphicsfd skipauth=1
> error : qemuMonitorOpenGraphics:3508 : invalid argument: monitor must
> not be NULL
> debug : qemuDomainObjExitMonitorInternal:3160 : Exited monitor
> (mon=(nil) vm=0x7f8f340140c0 name=ble)
> debug : qemuDomainObjEndJob:3068 : Stopping job: modify (async=none
> vm=0x7f8f340140c0 name=ble)
> 
> Signed-off-by: Jiri Denemark 
> ---
>  src/qemu/qemu_driver.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)

ACK

Michal

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Alex Williamson]

On Tue, 20 Sep 2016 20:05:01 +0530
Kirti Wankhede  wrote:

> On 9/20/2016 3:55 AM, Alex Williamson wrote:
> > On Mon, 19 Sep 2016 23:50:56 +0200
> > Paolo Bonzini  wrote:
> >   
> >> On 19/09/2016 23:36, Alex Williamson wrote:  
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede  wrote:
>  'fb_length':
>  Read-only file. Mandatory.
>  Returns {K,M,G}, size of framebuffer.
> >>>
> >>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> >>> just one user of mediated devices. [...]
> >>> 
>  'params'
>  Write-Only file. Optional.
>  String input. Libvirt would pass the string given in XML file to
>  this file and then create mdev device. Set empty string to clear params.
>  For example, set parameter 'frame_rate_limiter=0' to disable frame rate
>  limiter for performance benchmarking, then create device of type 11. The
>  device created would have that parameter set by vendor driver.
> >>>
> >>> Might as well just call it "magic", there's absolutely no ability to
> >>> introspect what parameters are allowed or even valid here.  Can all
> >>> parameters be changed dynamically?  Do parameter changes apply to
> >>> existing devices or only future devices?  This is a poorly specified
> >>> interface.  I'd prefer this be done via module options on the vendor
> >>> driver.
> >>
> >> Or additional files in the mdev's sysfs directory?  
> > 
> > Sure, the vendor driver could certainly support that, it'd be vendor
> > specific of course.
> >  
> 
> Right, it would be vendor specific. But if this is not set through mdev
> device XML, user have to create mdev device with XML first and then
> manually set such parameter. Also these parameters would not retain if
> mdev device is destroyed and created again. That's why if libvirt sets
> these parameters by reading it from XML file, it would be simple for user.
> 
> If we move 'params' file to mdev device, could libvirt do the following
> to create mdev device:
> 
> * Read /sys/../\:86\:00.0/11/max_instances. If it is greater than 0,
> then only proceed else fail.
> 
> * Autogenerate UUID
> * Create device:
> 
> echo "$UUID" > /sys/../\:86\:00.0/11/create
> 
> * Set extra params if 'params' field exist in device XML and 'params'
> file exist mdev device directory:
> 
> echo "frame_rate_limiter=0" > /sys/bus/mdev/devices/$UUID/params

Why does libvirt even need to participate in setting these additional
parameters?  The example here is for benchmarking, which doesn't
express to me a strong need to be automated through libvirt.  For
hostdev devices libvirt supports a managed='no' option that requires
the user to setup the device in advance.  Something similar sounds
reasonable here too.

This is also where I see that a vendor module option could be used,
something like:

modprobe nvidia enable-no-frl-mdev

You say you don't want to apply this to all mdev devices, but maybe it
just makes an additional type-id available "GRID-M60-0B-NOFRL".  Then
you've removed libvirt from the equation, the VM simply specifies this
type-id that incorporates that feature.  Obviously it gets complicated
if there are multiple features to enable, but we've only seen one
example so far of why this parameter is needed.  Thanks,

Alex

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Paolo Bonzini]

On 20/09/2016 16:41, Daniel P. Berrange wrote:
> As I've said in my earlier reply - libvirt will *NOT* support passing
> arbitrary vendor specific parameters as a blob via the XML. Everything
> that appears in the XML must be *fully* specified and explicitly
> represented in the XML  as a distinct attribute or element.

Are generic key/value attributes (e.g. a  element) acceptable?

Paolo

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 08:05:01PM +0530, Kirti Wankhede wrote:
> 
> 
> On 9/20/2016 3:55 AM, Alex Williamson wrote:
> > On Mon, 19 Sep 2016 23:50:56 +0200
> > Paolo Bonzini  wrote:
> > 
> >> On 19/09/2016 23:36, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede  wrote:  
>  'fb_length':
>  Read-only file. Mandatory.
>  Returns {K,M,G}, size of framebuffer.  
> >>>
> >>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> >>> just one user of mediated devices. [...]
> >>>   
>  'params'
>  Write-Only file. Optional.
>  String input. Libvirt would pass the string given in XML file to
>  this file and then create mdev device. Set empty string to clear params.
>  For example, set parameter 'frame_rate_limiter=0' to disable frame rate
>  limiter for performance benchmarking, then create device of type 11. The
>  device created would have that parameter set by vendor driver.  
> >>>
> >>> Might as well just call it "magic", there's absolutely no ability to
> >>> introspect what parameters are allowed or even valid here.  Can all
> >>> parameters be changed dynamically?  Do parameter changes apply to
> >>> existing devices or only future devices?  This is a poorly specified
> >>> interface.  I'd prefer this be done via module options on the vendor
> >>> driver.  
> >>
> >> Or additional files in the mdev's sysfs directory?
> > 
> > Sure, the vendor driver could certainly support that, it'd be vendor
> > specific of course.
> >
> 
> Right, it would be vendor specific. But if this is not set through mdev
> device XML, user have to create mdev device with XML first and then
> manually set such parameter. Also these parameters would not retain if
> mdev device is destroyed and created again. That's why if libvirt sets
> these parameters by reading it from XML file, it would be simple for user.
> 
> If we move 'params' file to mdev device, could libvirt do the following
> to create mdev device:
> 
> * Read /sys/../\:86\:00.0/11/max_instances. If it is greater than 0,
> then only proceed else fail.
> 
> * Autogenerate UUID
> * Create device:
> 
> echo "$UUID" > /sys/../\:86\:00.0/11/create
> 
> * Set extra params if 'params' field exist in device XML and 'params'
> file exist mdev device directory:
> 
> echo "frame_rate_limiter=0" > /sys/bus/mdev/devices/$UUID/params

As I've said in my earlier reply - libvirt will *NOT* support passing
arbitrary vendor specific parameters as a blob via the XML. Everything
that appears in the XML must be *fully* specified and explicitly
represented in the XML  as a distinct attribute or element.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Alex Williamson]

On Tue, 20 Sep 2016 19:51:58 +0530
Kirti Wankhede  wrote:

> On 9/20/2016 3:06 AM, Alex Williamson wrote:
> > On Tue, 20 Sep 2016 02:05:52 +0530
> > Kirti Wankhede  wrote:
> >   
> >> Hi libvirt experts,
> >>
> >> Thanks for valuable input on v1 version of RFC.
> >>
> >> Quick brief, VFIO based mediated device framework provides a way to
> >> virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT
> >> and IBM's channel IO. This framework reuses VFIO APIs for all the
> >> functionalities for mediated devices which are currently being used for
> >> pass through devices. This framework introduces a set of new sysfs files
> >> for device creation and its life cycle management.
> >>
> >> Here is the summary of discussion on v1:
> >> 1. Discover mediated device:
> >> As part of physical device initialization process, vendor driver will
> >> register their physical devices, which will be used to create virtual
> >> device (mediated device, aka mdev) to the mediated framework.
> >>
> >> Vendor driver should specify mdev_supported_types in directory format.
> >> This format is class based, for example, display class directory format
> >> should be as below. We need to define such set for each class of devices
> >> which would be supported by mediated device framework.
> >>
> >>  --- mdev_destroy  
> > 
> > I thought we replaced mdev_destroy with a remove attribute for each
> > mdev device.
> >   
> >>  --- mdev_supported_types
> >>  |-- 11
> >>  |   |-- create
> >>  |   |-- name
> >>  |   |-- fb_length
> >>  |   |-- resolution
> >>  |   |-- heads
> >>  |   |-- max_instances
> >>  |   |-- params
> >>  |   |-- requires_group
> >>  |-- 12
> >>  |   |-- create
> >>  |   |-- name
> >>  |   |-- fb_length
> >>  |   |-- resolution
> >>  |   |-- heads
> >>  |   |-- max_instances
> >>  |   |-- params
> >>  |   |-- requires_group
> >>  |-- 13
> >>  |-- create
> >>  |-- name
> >>  |-- fb_length
> >>  |-- resolution
> >>  |-- heads
> >>  |-- max_instances
> >>  |-- params
> >>  |-- requires_group
> >>
> >>
> >> In the above example directory '11' represents a type id of mdev device.
> >> 'name', 'fb_length', 'resolution', 'heads', 'max_instance' and
> >> 'requires_group' would be Read-Only files that vendor would provide to
> >> describe about that type.
> >>
> >> 'create':
> >> Write-only file. Mandatory.
> >> Accepts string to create mediated device.
> >>
> >> 'name':
> >> Read-Only file. Mandatory.
> >> Returns string, the name of that type id.
> >>
> >> 'fb_length':
> >> Read-only file. Mandatory.
> >> Returns {K,M,G}, size of framebuffer.  
> > 
> > This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> > just one user of mediated devices.
> >   
> 
> As per our discussion in BOF, we would define class and its attributes.
> As I mentioned above these are attributes of "display" class.

Just as I didn't know here, how does libvirt know the class of a given
type id?
 
> >>
> >> 'resolution':
> >> Read-Only file. Mandatory.
> >> Returns 'hres x vres' format. Maximum supported resolution.  
> > 
> > Same.
> >   
> >>
> >> 'heads':
> >> Read-Only file. Mandatory.
> >> Returns integer. Number of maximum heads supported.  
> > 
> > Same.
> >   
> >>
> >> 'max_instance':
> >> Read-Only file. Mandatory.
> >> Returns integer.  Returns maximum mdev device could be created
> >> at the moment when this file is read. This count would be updated by
> >> vendor driver. Before creating mdev device of this type, check if
> >> max_instance is > 0.  
> > 
> > Didn't we discuss this being being something like "available_instances"
> > with a "devices" sub-directory linking current devices of that type?
> >  
> 
> I'm ok with 'available_instances' as name of this file.
> Yes, mdev device directory will have links to devices of that type. I
> think that is part of mdev core module discussion. I'm trying to list
> sysfs files for libvirt interface here to focus more on libvirt
> interface. Hence didn't add that. I'll make sure to add all such details
> in future.
> 
> 
> >> 'params'
> >> Write-Only file. Optional.
> >> String input. Libvirt would pass the string given in XML file to
> >> this file and then create mdev device. Set empty string to clear params.
> >> For example, set parameter 'frame_rate_limiter=0' to disable frame rate
> >> limiter for performance benchmarking, then create device of type 11. The
> >> device created would have that parameter set by vendor driver.  
> > 
> > Might as well just call it "magic", there's absolutely no ability to
> > introspect what parameters are allowed or even valid here.  
> 
> Libvirt don't need to introspect these parameters. These are meant for
> vendor driver. Let vendor driver interpret these parameters and take
> action 

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Kirti Wankhede]

On 9/20/2016 3:55 AM, Alex Williamson wrote:
> On Mon, 19 Sep 2016 23:50:56 +0200
> Paolo Bonzini  wrote:
> 
>> On 19/09/2016 23:36, Alex Williamson wrote:
>>> On Tue, 20 Sep 2016 02:05:52 +0530
>>> Kirti Wankhede  wrote:  
 'fb_length':
 Read-only file. Mandatory.
 Returns {K,M,G}, size of framebuffer.  
>>>
>>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
>>> just one user of mediated devices. [...]
>>>   
 'params'
 Write-Only file. Optional.
 String input. Libvirt would pass the string given in XML file to
 this file and then create mdev device. Set empty string to clear params.
 For example, set parameter 'frame_rate_limiter=0' to disable frame rate
 limiter for performance benchmarking, then create device of type 11. The
 device created would have that parameter set by vendor driver.  
>>>
>>> Might as well just call it "magic", there's absolutely no ability to
>>> introspect what parameters are allowed or even valid here.  Can all
>>> parameters be changed dynamically?  Do parameter changes apply to
>>> existing devices or only future devices?  This is a poorly specified
>>> interface.  I'd prefer this be done via module options on the vendor
>>> driver.  
>>
>> Or additional files in the mdev's sysfs directory?
> 
> Sure, the vendor driver could certainly support that, it'd be vendor
> specific of course.
>

Right, it would be vendor specific. But if this is not set through mdev
device XML, user have to create mdev device with XML first and then
manually set such parameter. Also these parameters would not retain if
mdev device is destroyed and created again. That's why if libvirt sets
these parameters by reading it from XML file, it would be simple for user.

If we move 'params' file to mdev device, could libvirt do the following
to create mdev device:

* Read /sys/../\:86\:00.0/11/max_instances. If it is greater than 0,
then only proceed else fail.

* Autogenerate UUID
* Create device:

echo "$UUID" > /sys/../\:86\:00.0/11/create

* Set extra params if 'params' field exist in device XML and 'params'
file exist mdev device directory:

echo "frame_rate_limiter=0" > /sys/bus/mdev/devices/$UUID/params

Kirti

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

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

[Kirti Wankhede]

On 9/20/2016 3:06 AM, Alex Williamson wrote:
> On Tue, 20 Sep 2016 02:05:52 +0530
> Kirti Wankhede  wrote:
> 
>> Hi libvirt experts,
>>
>> Thanks for valuable input on v1 version of RFC.
>>
>> Quick brief, VFIO based mediated device framework provides a way to
>> virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT
>> and IBM's channel IO. This framework reuses VFIO APIs for all the
>> functionalities for mediated devices which are currently being used for
>> pass through devices. This framework introduces a set of new sysfs files
>> for device creation and its life cycle management.
>>
>> Here is the summary of discussion on v1:
>> 1. Discover mediated device:
>> As part of physical device initialization process, vendor driver will
>> register their physical devices, which will be used to create virtual
>> device (mediated device, aka mdev) to the mediated framework.
>>
>> Vendor driver should specify mdev_supported_types in directory format.
>> This format is class based, for example, display class directory format
>> should be as below. We need to define such set for each class of devices
>> which would be supported by mediated device framework.
>>
>>  --- mdev_destroy
> 
> I thought we replaced mdev_destroy with a remove attribute for each
> mdev device.
> 
>>  --- mdev_supported_types
>>  |-- 11
>>  |   |-- create
>>  |   |-- name
>>  |   |-- fb_length
>>  |   |-- resolution
>>  |   |-- heads
>>  |   |-- max_instances
>>  |   |-- params
>>  |   |-- requires_group
>>  |-- 12
>>  |   |-- create
>>  |   |-- name
>>  |   |-- fb_length
>>  |   |-- resolution
>>  |   |-- heads
>>  |   |-- max_instances
>>  |   |-- params
>>  |   |-- requires_group
>>  |-- 13
>>  |-- create
>>  |-- name
>>  |-- fb_length
>>  |-- resolution
>>  |-- heads
>>  |-- max_instances
>>  |-- params
>>  |-- requires_group
>>
>>
>> In the above example directory '11' represents a type id of mdev device.
>> 'name', 'fb_length', 'resolution', 'heads', 'max_instance' and
>> 'requires_group' would be Read-Only files that vendor would provide to
>> describe about that type.
>>
>> 'create':
>> Write-only file. Mandatory.
>> Accepts string to create mediated device.
>>
>> 'name':
>> Read-Only file. Mandatory.
>> Returns string, the name of that type id.
>>
>> 'fb_length':
>> Read-only file. Mandatory.
>> Returns {K,M,G}, size of framebuffer.
> 
> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
> just one user of mediated devices.
> 

As per our discussion in BOF, we would define class and its attributes.
As I mentioned above these are attributes of "display" class.

>>
>> 'resolution':
>> Read-Only file. Mandatory.
>> Returns 'hres x vres' format. Maximum supported resolution.
> 
> Same.
> 
>>
>> 'heads':
>> Read-Only file. Mandatory.
>> Returns integer. Number of maximum heads supported.
> 
> Same.
> 
>>
>> 'max_instance':
>> Read-Only file. Mandatory.
>> Returns integer.  Returns maximum mdev device could be created
>> at the moment when this file is read. This count would be updated by
>> vendor driver. Before creating mdev device of this type, check if
>> max_instance is > 0.
> 
> Didn't we discuss this being being something like "available_instances"
> with a "devices" sub-directory linking current devices of that type?
>

I'm ok with 'available_instances' as name of this file.
Yes, mdev device directory will have links to devices of that type. I
think that is part of mdev core module discussion. I'm trying to list
sysfs files for libvirt interface here to focus more on libvirt
interface. Hence didn't add that. I'll make sure to add all such details
in future.


>> 'params'
>> Write-Only file. Optional.
>> String input. Libvirt would pass the string given in XML file to
>> this file and then create mdev device. Set empty string to clear params.
>> For example, set parameter 'frame_rate_limiter=0' to disable frame rate
>> limiter for performance benchmarking, then create device of type 11. The
>> device created would have that parameter set by vendor driver.
> 
> Might as well just call it "magic", there's absolutely no ability to
> introspect what parameters are allowed or even valid here.

Libvirt don't need to introspect these parameters. These are meant for
vendor driver. Let vendor driver interpret these parameters and take
action based on that.

>  Can all parameters be changed dynamically?

Parameters here would be extra parameters which are not listed above in
mandatory list. If such parameters are required to set, these parameters
should be set per mdev device before VM is booted.

>  Do parameter changes apply to existing devices or only future devices?

No, it should be applied at the time when mdev device is created or
after mdev device is created but before VM is 

Re: [libvirt] [PATCH v2] qemu-migration: Disallow migration of read only disk

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 03:53:16PM +0200, Peter Krempa wrote:
> On Tue, Sep 20, 2016 at 09:40:22 -0400, Corey S. McQuay wrote:
> > Currently Libvirt allows attempts to migrate read only disks. Qemu cannot 
> > handle this as read only
> > disks cannot be written to on the destination system. The end result is a 
> > cryptic error message
> > and a failed migration.
> 
> This is not necessarily true. Read only disks can sometimes be in fact
> backed by storage that is writable and it's desired to be migrated.

If 'def->readonly' is true, then the security drivers won't allow
QEMU to write to the image, regardless of whether the underlying
storage is writable.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [PATCH] virtlogd: Don't stop or restart along with libvirtd

[Andrea Bolognani]

On Tue, 2016-09-20 at 14:35 +0100, Daniel P. Berrange wrote:
> ACK

Pushed, thanks.

> FYI, systemd docs say
> 
>PartOf=
>Configures dependencies similar to Requires=, but limited to
>stopping and restarting of units. When systemd stops or restarts
>the units listed here, the action is propagated to this unit. Note
>that this is a one-way dependency — changes to this unit do not
>affect the listed units.
> 
> we clearly don't want 'restart' propagated to virtlogd
> or virtlockd - those units must only ever 'reexec'
> themselves.

I was aware of that; however, I failed to understand that
virtlogd must never be restarted this way.

Thankfully downstream QE caught the faulty commit before
it could make it into a release :)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [PATCH v2] qemu-migration: Disallow migration of read only disk

[Peter Krempa]

On Tue, Sep 20, 2016 at 09:40:22 -0400, Corey S. McQuay wrote:
> Currently Libvirt allows attempts to migrate read only disks. Qemu cannot 
> handle this as read only
> disks cannot be written to on the destination system. The end result is a 
> cryptic error message
> and a failed migration.

This is not necessarily true. Read only disks can sometimes be in fact
backed by storage that is writable and it's desired to be migrated.

I think you want to specify which storage to migrate using the
VIR_MIGRATE_PARAM_MIGRATE_DISKS migration parameter for
virDomainMigrate3.

http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrate3

http://libvirt.org/html/libvirt-libvirt-domain.html#VIR_MIGRATE_PARAM_MIGRATE_DISKS

Virsh also implements support for that flag.

> This patch causes migration to fail earlier and provides a meaningful error 
> message stating that
> migrating read only disks is not supported.
> 
> Signed-off-by: Corey S. McQuay 
> Reviewed-by: Jason J. Herne 
> Reviewed-by: Boris Fiuczynski 
> ---
>  src/qemu/qemu_migration.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index e451ef6..011f349 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -2157,6 +2157,13 @@ qemuMigrationDriveMirror(virQEMUDriverPtr driver,
>  if (!qemuMigrateDisk(disk, nmigrate_disks, migrate_disks))
>  continue;
>  
> +if (disk->src->readonly) {
> +virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
> +   _("Cannot migrate read-only disk %s"),
> +   disk->dst);
> +goto cleanup;
> +}

NACK this would break the above use case. You want to specify explicitly
which storage to migrate using the above described API.

Peter

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

[libvirt] [PATCH 0/9] Couple of migration fixes

[Michal Privoznik]

Looks like nobody tried migrations lately. I just did and found
interesting bug. On the destination qemu binary was at different
path. So I've dumped domain XML I was trying ti migrate and just
changed the emulator path. All of a sudden I observed plenty of
errors. Problem is that whilst parsing the user provided
migration XML (and doing other operations on it), because of
parse callbacks we need qemuCaps for the binary. However, we just
take the def->emulator and expect it to exist. Well, it doesn't.

Michal Privoznik (9):
  conf: Introduce virDomainDefPostParseOpaque
  conf: Introduce virDomainDefParseStringOpaque
  qemuDomainDefPostParse: Fetch qemuCaps from domain object
  conf: Extend virDomainDeviceDefPostParse for parseOpaque
  qemuDomainDeviceDefPostParse: Fetch caps from domain object
  conf: Extend virDomainDefAssignAddressesCallback for parseOpaque
  qemuDomainDefAssignAddresses: Fetch caps from domain object
  domain_conf: Introduce VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE
  conf: Skip post parse callbacks when creating copy

 src/bhyve/bhyve_domain.c   |  6 ++--
 src/conf/domain_conf.c | 80 +-
 src/conf/domain_conf.h | 43 +
 src/libvirt_private.syms   |  3 ++
 src/libxl/libxl_domain.c   |  6 ++--
 src/lxc/lxc_domain.c   |  6 ++--
 src/openvz/openvz_driver.c |  6 ++--
 src/phyp/phyp_driver.c |  6 ++--
 src/qemu/qemu_domain.c | 50 ++---
 src/qemu/qemu_migration.c  |  6 ++--
 src/uml/uml_driver.c   |  6 ++--
 src/vbox/vbox_common.c |  6 ++--
 src/vmware/vmware_driver.c |  6 ++--
 src/vmx/vmx.c  |  6 ++--
 src/vz/vz_driver.c |  6 ++--
 src/xen/xen_driver.c   |  6 ++--
 src/xenapi/xenapi_driver.c |  6 ++--
 17 files changed, 195 insertions(+), 59 deletions(-)

-- 
2.8.4

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

[libvirt] [PATCH 2/9] conf: Introduce virDomainDefParseStringOpaque

[Michal Privoznik]

This function allows callers to pass arbitrary pointer to domain
def parse callback.

Signed-off-by: Michal Privoznik 
---
 src/conf/domain_conf.c   | 37 ++---
 src/conf/domain_conf.h   | 11 +++
 src/libvirt_private.syms |  2 ++
 3 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e8c8465..91cd2ab 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -15881,6 +15881,7 @@ virDomainDefParseXML(xmlDocPtr xml,
  xmlXPathContextPtr ctxt,
  virCapsPtr caps,
  virDomainXMLOptionPtr xmlopt,
+ void *parseOpaque,
  unsigned int flags)
 {
 xmlNodePtr *nodes = NULL, node = NULL;
@@ -17532,7 +17533,7 @@ virDomainDefParseXML(xmlDocPtr xml,
 goto error;
 
 /* callback to fill driver specific domain aspects */
-if (virDomainDefPostParse(def, caps, flags, xmlopt) < 0)
+if (virDomainDefPostParseOpaque(def, caps, flags, xmlopt, parseOpaque) < 0)
 goto error;
 
 /* valdiate configuration */
@@ -17581,7 +17582,7 @@ virDomainObjParseXML(xmlDocPtr xml,
 
 oldnode = ctxt->node;
 ctxt->node = config;
-obj->def = virDomainDefParseXML(xml, config, ctxt, caps, xmlopt, flags);
+obj->def = virDomainDefParseXML(xml, config, ctxt, caps, xmlopt, NULL, 
flags);
 ctxt->node = oldnode;
 if (!obj->def)
 goto error;
@@ -17654,6 +17655,7 @@ virDomainDefParse(const char *xmlStr,
   const char *filename,
   virCapsPtr caps,
   virDomainXMLOptionPtr xmlopt,
+  void *parseOpaque,
   unsigned int flags)
 {
 xmlDocPtr xml;
@@ -17661,8 +17663,8 @@ virDomainDefParse(const char *xmlStr,
 int keepBlanksDefault = xmlKeepBlanksDefault(0);
 
 if ((xml = virXMLParse(filename, xmlStr, _("(domain_definition)" {
-def = virDomainDefParseNode(xml, xmlDocGetRootElement(xml), caps,
-xmlopt, flags);
+def = virDomainDefParseNodeOpaque(xml, xmlDocGetRootElement(xml), caps,
+  xmlopt, parseOpaque, flags);
 xmlFreeDoc(xml);
 }
 
@@ -17676,7 +17678,17 @@ virDomainDefParseString(const char *xmlStr,
 virDomainXMLOptionPtr xmlopt,
 unsigned int flags)
 {
-return virDomainDefParse(xmlStr, NULL, caps, xmlopt, flags);
+return virDomainDefParse(xmlStr, NULL, caps, xmlopt, NULL, flags);
+}
+
+virDomainDefPtr
+virDomainDefParseStringOpaque(const char *xmlStr,
+  virCapsPtr caps,
+  virDomainXMLOptionPtr xmlopt,
+  void *parseOpaque,
+  unsigned int flags)
+{
+return virDomainDefParse(xmlStr, NULL, caps, xmlopt, parseOpaque, flags);
 }
 
 virDomainDefPtr
@@ -17685,7 +17697,7 @@ virDomainDefParseFile(const char *filename,
   virDomainXMLOptionPtr xmlopt,
   unsigned int flags)
 {
-return virDomainDefParse(NULL, filename, caps, xmlopt, flags);
+return virDomainDefParse(NULL, filename, caps, xmlopt, NULL, flags);
 }
 
 
@@ -17696,6 +17708,17 @@ virDomainDefParseNode(xmlDocPtr xml,
   virDomainXMLOptionPtr xmlopt,
   unsigned int flags)
 {
+return virDomainDefParseNodeOpaque(xml, root, caps, xmlopt, NULL, flags);
+}
+
+virDomainDefPtr
+virDomainDefParseNodeOpaque(xmlDocPtr xml,
+xmlNodePtr root,
+virCapsPtr caps,
+virDomainXMLOptionPtr xmlopt,
+void *parseOpaque,
+unsigned int flags)
+{
 xmlXPathContextPtr ctxt = NULL;
 virDomainDefPtr def = NULL;
 
@@ -17714,7 +17737,7 @@ virDomainDefParseNode(xmlDocPtr xml,
 }
 
 ctxt->node = root;
-def = virDomainDefParseXML(xml, root, ctxt, caps, xmlopt, flags);
+def = virDomainDefParseXML(xml, root, ctxt, caps, xmlopt, parseOpaque, 
flags);
 
  cleanup:
 xmlXPathFreeContext(ctxt);
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 6056aa7..f132153 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2679,6 +2679,11 @@ virDomainDefPtr virDomainDefParseString(const char 
*xmlStr,
 virCapsPtr caps,
 virDomainXMLOptionPtr xmlopt,
 unsigned int flags);
+virDomainDefPtr virDomainDefParseStringOpaque(const char *xmlStr,
+  virCapsPtr caps,
+  virDomainXMLOptionPtr xmlopt,
+  void *parseOpaque,
+  unsigned 

[libvirt] [PATCH 1/9] conf: Introduce virDomainDefPostParseOpaque

[Michal Privoznik]

Some callers might want to pass yet another pointer to opaque
data to post parse callbacks. The driver generic one is not
enough because two threads executing post parse callback might
want see different data (e.g. domain object pointer that domain
def belongs to).

Signed-off-by: Michal Privoznik 
---
 src/bhyve/bhyve_domain.c   |  3 ++-
 src/conf/domain_conf.c | 13 -
 src/conf/domain_conf.h | 14 --
 src/libvirt_private.syms   |  1 +
 src/libxl/libxl_domain.c   |  3 ++-
 src/lxc/lxc_domain.c   |  3 ++-
 src/openvz/openvz_driver.c |  3 ++-
 src/phyp/phyp_driver.c |  3 ++-
 src/qemu/qemu_domain.c |  3 ++-
 src/uml/uml_driver.c   |  3 ++-
 src/vbox/vbox_common.c |  3 ++-
 src/vmware/vmware_driver.c |  3 ++-
 src/vmx/vmx.c  |  3 ++-
 src/vz/vz_driver.c |  3 ++-
 src/xen/xen_driver.c   |  3 ++-
 src/xenapi/xenapi_driver.c |  3 ++-
 16 files changed, 51 insertions(+), 16 deletions(-)

diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c
index 89cb171..3273462 100644
--- a/src/bhyve/bhyve_domain.c
+++ b/src/bhyve/bhyve_domain.c
@@ -61,7 +61,8 @@ static int
 bhyveDomainDefPostParse(virDomainDefPtr def,
 virCapsPtr caps ATTRIBUTE_UNUSED,
 unsigned int parseFlags ATTRIBUTE_UNUSED,
-void *opaque ATTRIBUTE_UNUSED)
+void *opaque ATTRIBUTE_UNUSED,
+void *parseOpaque ATTRIBUTE_UNUSED)
 {
 /* Add an implicit PCI root controller */
 if (virDomainDefMaybeAddController(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 0,
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index b4a3e92..e8c8465 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -4532,6 +4532,16 @@ virDomainDefPostParse(virDomainDefPtr def,
   unsigned int parseFlags,
   virDomainXMLOptionPtr xmlopt)
 {
+return virDomainDefPostParseOpaque(def, caps, parseFlags, xmlopt, NULL);
+}
+
+int
+virDomainDefPostParseOpaque(virDomainDefPtr def,
+virCapsPtr caps,
+unsigned int parseFlags,
+virDomainXMLOptionPtr xmlopt,
+void *parseOpaque)
+{
 int ret;
 struct virDomainDefPostParseDeviceIteratorData data = {
 .caps = caps,
@@ -4547,7 +4557,8 @@ virDomainDefPostParse(virDomainDefPtr def,
 /* call the domain config callback */
 if (xmlopt->config.domainPostParseCallback) {
 ret = xmlopt->config.domainPostParseCallback(def, caps, parseFlags,
- xmlopt->config.priv);
+ xmlopt->config.priv,
+ parseOpaque);
 if (ret < 0)
 return ret;
 }
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index c14a39c..6056aa7 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2361,11 +2361,15 @@ typedef struct _virDomainXMLOption virDomainXMLOption;
 typedef virDomainXMLOption *virDomainXMLOptionPtr;
 
 /* Called once after everything else has been parsed, for adjusting
- * overall domain defaults.  */
+ * overall domain defaults.
+ * @parseOpaque is opaque data passed by virDomainDefParse* caller,
+ * @opqaue is opaque data set by driver (usually pointer to driver
+ * private data). */
 typedef int (*virDomainDefPostParseCallback)(virDomainDefPtr def,
  virCapsPtr caps,
  unsigned int parseFlags,
- void *opaque);
+ void *opaque,
+ void *parseOpaque);
 /* Called once per device, for adjusting per-device settings while
  * leaving the overall domain otherwise unchanged.  */
 typedef int (*virDomainDeviceDefPostParseCallback)(virDomainDeviceDefPtr dev,
@@ -2453,6 +2457,12 @@ virDomainDefPostParse(virDomainDefPtr def,
   unsigned int parseFlags,
   virDomainXMLOptionPtr xmlopt);
 
+int virDomainDefPostParseOpaque(virDomainDefPtr def,
+virCapsPtr caps,
+unsigned int parseFlags,
+virDomainXMLOptionPtr xmlopt,
+void *parseOpaque);
+
 int virDomainDefValidate(virDomainDefPtr def,
  virCapsPtr caps,
  unsigned int parseFlags,
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 9610e0c..5fd1178 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -250,6 +250,7 @@ virDomainDefParseFile;
 virDomainDefParseNode;
 virDomainDefParseString;
 virDomainDefPostParse;
+virDomainDefPostParseOpaque;
 

[libvirt] [PATCH 5/9] qemuDomainDeviceDefPostParse: Fetch caps from domain object

[Michal Privoznik]

Just like we did two commits ago, don't try to fetch capabilities
for non-existing binary. Re-use the ones we have for running
domain.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_domain.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 034ab73..36c0f29 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2564,14 +2564,22 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
  virCapsPtr caps ATTRIBUTE_UNUSED,
  unsigned int parseFlags,
  void *opaque,
- void *parseOpaque ATTRIBUTE_UNUSED)
+ void *parseOpaque)
 {
 virQEMUDriverPtr driver = opaque;
 virQEMUCapsPtr qemuCaps = NULL;
 virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
+virDomainObjPtr vm = parseOpaque;
+qemuDomainObjPrivatePtr priv;
 int ret = -1;
 
-qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache, def->emulator);
+if (vm) {
+priv = vm->privateData;
+qemuCaps = priv->qemuCaps;
+virObjectRef(qemuCaps);
+} else {
+qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache, 
def->emulator);
+}
 
 if (dev->type == VIR_DOMAIN_DEVICE_NET &&
 dev->data.net->type != VIR_DOMAIN_NET_TYPE_HOSTDEV &&
-- 
2.8.4

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

[libvirt] [PATCH 9/9] conf: Skip post parse callbacks when creating copy

[Michal Privoznik]

When creating a copy of virDomainDef we save ourselves the
trouble of writing deep-copy functions and just format and parse
back domain/device XML. However, the XML we are parsing was
already fully formatted - there is no reason to run post parse
callbacks (which fill in blanks - there are none!).

Signed-off-by: Michal Privoznik 
---
 src/conf/domain_conf.c | 6 --
 src/qemu/qemu_domain.c | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 7e4aba6..e9a48d2 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -24603,7 +24603,8 @@ virDomainDefCopy(virDomainDefPtr src,
 virDomainDefPtr ret;
 unsigned int format_flags = VIR_DOMAIN_DEF_FORMAT_SECURE;
 unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE |
-   VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE;
+   VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE |
+   VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE;
 
 if (migratable)
 format_flags |= VIR_DOMAIN_DEF_FORMAT_INACTIVE | 
VIR_DOMAIN_DEF_FORMAT_MIGRATABLE;
@@ -25090,7 +25091,8 @@ virDomainDeviceDefCopy(virDomainDeviceDefPtr src,
 xmlStr = virBufferContentAndReset();
 ret = virDomainDeviceDefParse(xmlStr, def, caps, xmlopt,
   VIR_DOMAIN_DEF_PARSE_INACTIVE |
-  VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE);
+  VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE |
+  VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE);
 
  cleanup:
 VIR_FREE(xmlStr);
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index d3af622..13e1319 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -3388,7 +3388,8 @@ qemuDomainDefCopy(virQEMUDriverPtr driver,
 
 if (!(ret = virDomainDefParseString(xml, caps, driver->xmlopt,
 VIR_DOMAIN_DEF_PARSE_INACTIVE |
-VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE)))
+VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE |
+VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE)))
 goto cleanup;
 
  cleanup:
-- 
2.8.4

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

[libvirt] [PATCH 4/9] conf: Extend virDomainDeviceDefPostParse for parseOpaque

[Michal Privoznik]

Just like virDomainDefPostParseCallback has gained new
parseOpaque argument, we need to follow the logic with
virDomainDeviceDefPostParse.

Signed-off-by: Michal Privoznik 
---
 src/bhyve/bhyve_domain.c   |  3 ++-
 src/conf/domain_conf.c | 13 +
 src/conf/domain_conf.h |  8 ++--
 src/libxl/libxl_domain.c   |  3 ++-
 src/lxc/lxc_domain.c   |  3 ++-
 src/openvz/openvz_driver.c |  3 ++-
 src/phyp/phyp_driver.c |  3 ++-
 src/qemu/qemu_domain.c |  3 ++-
 src/qemu/qemu_migration.c  |  6 +++---
 src/uml/uml_driver.c   |  3 ++-
 src/vbox/vbox_common.c |  3 ++-
 src/vmware/vmware_driver.c |  3 ++-
 src/vmx/vmx.c  |  3 ++-
 src/vz/vz_driver.c |  3 ++-
 src/xen/xen_driver.c   |  3 ++-
 src/xenapi/xenapi_driver.c |  3 ++-
 16 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c
index 3273462..e2a20ce 100644
--- a/src/bhyve/bhyve_domain.c
+++ b/src/bhyve/bhyve_domain.c
@@ -77,7 +77,8 @@ bhyveDomainDeviceDefPostParse(virDomainDeviceDefPtr dev 
ATTRIBUTE_UNUSED,
   const virDomainDef *def ATTRIBUTE_UNUSED,
   virCapsPtr caps ATTRIBUTE_UNUSED,
   unsigned int parseFlags ATTRIBUTE_UNUSED,
-  void *opaque ATTRIBUTE_UNUSED)
+  void *opaque ATTRIBUTE_UNUSED,
+  void *parseOpaque ATTRIBUTE_UNUSED)
 {
 return 0;
 }
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 91cd2ab..a4bc33f 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -4391,13 +4391,15 @@ virDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
 const virDomainDef *def,
 virCapsPtr caps,
 unsigned int flags,
-virDomainXMLOptionPtr xmlopt)
+virDomainXMLOptionPtr xmlopt,
+void *parseOpaque)
 {
 int ret;
 
 if (xmlopt->config.devicesPostParseCallback) {
 ret = xmlopt->config.devicesPostParseCallback(dev, def, caps, flags,
-  xmlopt->config.priv);
+  xmlopt->config.priv,
+  parseOpaque);
 if (ret < 0)
 return ret;
 }
@@ -4415,6 +4417,7 @@ virDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
 struct virDomainDefPostParseDeviceIteratorData {
 virCapsPtr caps;
 virDomainXMLOptionPtr xmlopt;
+void *parseOpaque;
 unsigned int parseFlags;
 };
 
@@ -4427,7 +4430,8 @@ virDomainDefPostParseDeviceIterator(virDomainDefPtr def,
 {
 struct virDomainDefPostParseDeviceIteratorData *data = opaque;
 return virDomainDeviceDefPostParse(dev, def, data->caps,
-   data->parseFlags, data->xmlopt);
+   data->parseFlags, data->xmlopt,
+   data->parseOpaque);
 }
 
 
@@ -4546,6 +4550,7 @@ virDomainDefPostParseOpaque(virDomainDefPtr def,
 struct virDomainDefPostParseDeviceIteratorData data = {
 .caps = caps,
 .xmlopt = xmlopt,
+.parseOpaque = parseOpaque,
 .parseFlags = parseFlags,
 };
 
@@ -13536,7 +13541,7 @@ virDomainDeviceDefParse(const char *xmlStr,
 }
 
 /* callback to fill driver specific device aspects */
-if (virDomainDeviceDefPostParse(dev, def, caps, flags, xmlopt) < 0)
+if (virDomainDeviceDefPostParse(dev, def, caps, flags, xmlopt, NULL) < 0)
 goto error;
 
 /* validate the configuration */
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index f132153..17f1edc 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2371,12 +2371,16 @@ typedef int 
(*virDomainDefPostParseCallback)(virDomainDefPtr def,
  void *opaque,
  void *parseOpaque);
 /* Called once per device, for adjusting per-device settings while
- * leaving the overall domain otherwise unchanged.  */
+ * leaving the overall domain otherwise unchanged.
+ * @parseOpaque is opaque data passed by virDomainDefParse* caller,
+ * @opqaue is opaque data set by driver (usually pointer to driver
+ * private data). */
 typedef int (*virDomainDeviceDefPostParseCallback)(virDomainDeviceDefPtr dev,
const virDomainDef *def,
virCapsPtr caps,
unsigned int parseFlags,
-   void *opaque);
+   void *opaque,
+   void *parseOpaque);
 /* 

[libvirt] [PATCH 3/9] qemuDomainDefPostParse: Fetch qemuCaps from domain object

[Michal Privoznik]

We can't rely on def->emulator path. It may be provided by user
as we give them opportunity to provide their own XML for
migration. Therefore the path may point to just whatever binary
(or even to a non-existent file). Moreover, this path is meant
for destination, but the capabilities lookup is done on source.
What we can do is to assume same capabilities for post parse
callbacks as the running domain has. They will be used just to
add some default models/controllers/devices/... anyway.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_domain.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index c26da14..8e2c9e9 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2327,11 +2327,13 @@ qemuDomainDefPostParse(virDomainDefPtr def,
virCapsPtr caps,
unsigned int parseFlags,
void *opaque,
-   void *parseOpaque ATTRIBUTE_UNUSED)
+   void *parseOpaque)
 {
 virQEMUDriverPtr driver = opaque;
 virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
 virQEMUCapsPtr qemuCaps = NULL;
+virDomainObjPtr vm = parseOpaque;
+qemuDomainObjPrivatePtr priv;
 int ret = -1;
 
 if (def->os.bootloader || def->os.bootloaderArgs) {
@@ -2360,9 +2362,15 @@ qemuDomainDefPostParse(virDomainDefPtr def,
 !(def->emulator = virDomainDefGetDefaultEmulator(def, caps)))
 goto cleanup;
 
-if (!(qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache,
-def->emulator)))
-goto cleanup;
+if (vm) {
+priv = vm->privateData;
+qemuCaps = priv->qemuCaps;
+virObjectRef(qemuCaps);
+} else {
+if (!(qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache,
+def->emulator)))
+goto cleanup;
+}
 
 if (qemuDomainDefAddDefaultDevices(def, qemuCaps) < 0)
 goto cleanup;
-- 
2.8.4

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

[libvirt] [PATCH 8/9] domain_conf: Introduce VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE

[Michal Privoznik]

This is an internal flag that prevents our two entry points to
XML parsing (virDomainDefParse and virDomainDeviceDefParse) from
running post parse callbacks. This is expected to be used in
cases when we already have full domain/device XML and we are just
parsing it back (i.e. virDomainDefCopy or virDomainDeviceDefCopy)

Signed-off-by: Michal Privoznik 
---
 src/conf/domain_conf.c | 8 
 src/conf/domain_conf.h | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 89a3f62..7e4aba6 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -4396,6 +4396,10 @@ virDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
 {
 int ret;
 
+/* fill in configuration only in certain places */
+if (flags & VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE)
+return 0;
+
 if (xmlopt->config.devicesPostParseCallback) {
 ret = xmlopt->config.devicesPostParseCallback(dev, def, caps, flags,
   xmlopt->config.priv,
@@ -4554,6 +4558,10 @@ virDomainDefPostParseOpaque(virDomainDefPtr def,
 .parseFlags = parseFlags,
 };
 
+/* fill in configuration only in certain places */
+if (parseFlags & VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE)
+return 0;
+
 /* this must be done before the hypervisor-specific callback,
  * in case presence of a controller at a specific index is checked
  */
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 17ade4b..7b097ab 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2647,6 +2647,8 @@ typedef enum {
 VIR_DOMAIN_DEF_PARSE_ABI_UPDATE = 1 << 9,
 /* skip definition validation checks meant to be executed on define time 
only */
 VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE = 1 << 10,
+/* skip post parse callback */
+VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE = 1 << 11,
 } virDomainDefParseFlags;
 
 typedef enum {
-- 
2.8.4

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

[libvirt] [PATCH 7/9] qemuDomainDefAssignAddresses: Fetch caps from domain object

[Michal Privoznik]

Just like we did two commits ago, don't try to fetch capabilities
for non-existing binary. Re-use the ones we have for running
domain.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_domain.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 81cb87a..d3af622 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2779,16 +2779,24 @@ qemuDomainDefAssignAddresses(virDomainDef *def,
  virCapsPtr caps ATTRIBUTE_UNUSED,
  unsigned int parseFlags ATTRIBUTE_UNUSED,
  void *opaque,
- void *parseOpaque ATTRIBUTE_UNUSED)
+ void *parseOpaque)
 {
 virQEMUDriverPtr driver = opaque;
+virDomainObjPtr vm = parseOpaque;
+qemuDomainObjPrivatePtr priv;
 virQEMUCapsPtr qemuCaps = NULL;
 int ret = -1;
 bool newDomain = parseFlags & VIR_DOMAIN_DEF_PARSE_ABI_UPDATE;
 
-if (!(qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache,
-def->emulator)))
-goto cleanup;
+if (vm) {
+priv = vm->privateData;
+qemuCaps = priv->qemuCaps;
+virObjectRef(qemuCaps);
+} else {
+if (!(qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache,
+def->emulator)))
+goto cleanup;
+}
 
 if (qemuDomainAssignAddresses(def, qemuCaps, NULL, newDomain) < 0)
 goto cleanup;
-- 
2.8.4

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

[libvirt] [PATCH 6/9] conf: Extend virDomainDefAssignAddressesCallback for parseOpaque

[Michal Privoznik]

Signed-off-by: Michal Privoznik 
---
 src/conf/domain_conf.c | 3 ++-
 src/conf/domain_conf.h | 8 ++--
 src/qemu/qemu_domain.c | 3 ++-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index a4bc33f..89a3f62 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -4581,7 +4581,8 @@ virDomainDefPostParseOpaque(virDomainDefPtr def,
 
 if (xmlopt->config.assignAddressesCallback) {
 ret = xmlopt->config.assignAddressesCallback(def, caps, parseFlags,
- xmlopt->config.priv);
+ xmlopt->config.priv,
+ parseOpaque);
 if (ret < 0)
 return ret;
 }
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 17f1edc..17ade4b 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2382,11 +2382,15 @@ typedef int 
(*virDomainDeviceDefPostParseCallback)(virDomainDeviceDefPtr dev,
void *opaque,
void *parseOpaque);
 /* Drive callback for assigning device addresses, called at the end
- * of parsing, after all defaults and implicit devices have been added.  */
+ * of parsing, after all defaults and implicit devices have been added.
+ * @parseOpaque is opaque data passed by virDomainDefParse* caller,
+ * @opqaue is opaque data set by driver (usually pointer to driver
+ * private data). */
 typedef int (*virDomainDefAssignAddressesCallback)(virDomainDef *def,
virCapsPtr caps,
unsigned int parseFlags,
-   void *opaque);
+   void *opaque,
+   void *parseOpaque);
 
 /* Called in appropriate places where the domain conf parser can return failure
  * for configurations that were previously accepted. This shall not modify the
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 36c0f29..81cb87a 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2778,7 +2778,8 @@ static int
 qemuDomainDefAssignAddresses(virDomainDef *def,
  virCapsPtr caps ATTRIBUTE_UNUSED,
  unsigned int parseFlags ATTRIBUTE_UNUSED,
- void *opaque)
+ void *opaque,
+ void *parseOpaque ATTRIBUTE_UNUSED)
 {
 virQEMUDriverPtr driver = opaque;
 virQEMUCapsPtr qemuCaps = NULL;
-- 
2.8.4

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

[libvirt] [PATCH] qemuDomainOpenGraphics: Start job early

[Jiri Denemark]

Checking if a domain's definition or if it is active before we got a job
is pointless since the domain might have changed in the meantime.

Luckily libvirtd didn't crash when the API tried to talk to an inactive
domain:

debug : qemuDomainObjBeginJobInternal:2914 : Started job: modify
(async=none vm=0x7f8f340140c0 name=ble)
debug : qemuDomainObjEnterMonitorInternal:3137 : Entering monitor
(mon=(nil) vm=0x7f8f340140c0 name=ble)
warning : virObjectLock:319 : Object (nil) ((unknown)) is not a
virObjectLockable instance
debug : qemuMonitorOpenGraphics:3505 : protocol=spice fd=27
fdname=graphicsfd skipauth=1
error : qemuMonitorOpenGraphics:3508 : invalid argument: monitor must
not be NULL
debug : qemuDomainObjExitMonitorInternal:3160 : Exited monitor
(mon=(nil) vm=0x7f8f340140c0 name=ble)
debug : qemuDomainObjEndJob:3068 : Stopping job: modify (async=none
vm=0x7f8f340140c0 name=ble)

Signed-off-by: Jiri Denemark 
---
 src/qemu/qemu_driver.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index e29180d..4c45fc3 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -17118,10 +17118,13 @@ qemuDomainOpenGraphics(virDomainPtr dom,
 if (virDomainOpenGraphicsEnsureACL(dom->conn, vm->def) < 0)
 goto cleanup;
 
+if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0)
+goto cleanup;
+
 if (!virDomainObjIsActive(vm)) {
 virReportError(VIR_ERR_OPERATION_INVALID,
"%s", _("domain is not running"));
-goto cleanup;
+goto endjob;
 }
 
 priv = vm->privateData;
@@ -17129,7 +17132,7 @@ qemuDomainOpenGraphics(virDomainPtr dom,
 if (idx >= vm->def->ngraphics) {
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("No graphics backend with index %d"), idx);
-goto cleanup;
+goto endjob;
 }
 switch (vm->def->graphics[idx]->type) {
 case VIR_DOMAIN_GRAPHICS_TYPE_VNC:
@@ -17142,20 +17145,20 @@ qemuDomainOpenGraphics(virDomainPtr dom,
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("Can only open VNC or SPICE graphics backends, not 
%s"),

virDomainGraphicsTypeToString(vm->def->graphics[idx]->type));
-goto cleanup;
+goto endjob;
 }
 
 if (virSecurityManagerSetImageFDLabel(driver->securityManager, vm->def,
   fd) < 0)
-goto cleanup;
+goto endjob;
 
-if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0)
-goto cleanup;
 qemuDomainObjEnterMonitor(driver, vm);
 ret = qemuMonitorOpenGraphics(priv->mon, protocol, fd, "graphicsfd",
   (flags & VIR_DOMAIN_OPEN_GRAPHICS_SKIPAUTH) 
!= 0);
 if (qemuDomainObjExitMonitor(driver, vm) < 0)
 ret = -1;
+
+ endjob:
 qemuDomainObjEndJob(driver, vm);
 
  cleanup:
-- 
2.10.0

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

[libvirt] [PATCH v2] qemu-migration: Disallow migration of read only disk

[Corey S. McQuay]

Currently Libvirt allows attempts to migrate read only disks. Qemu cannot 
handle this as read only
disks cannot be written to on the destination system. The end result is a 
cryptic error message
and a failed migration.

This patch causes migration to fail earlier and provides a meaningful error 
message stating that
migrating read only disks is not supported.

Signed-off-by: Corey S. McQuay 
Reviewed-by: Jason J. Herne 
Reviewed-by: Boris Fiuczynski 
---
 src/qemu/qemu_migration.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index e451ef6..011f349 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2157,6 +2157,13 @@ qemuMigrationDriveMirror(virQEMUDriverPtr driver,
 if (!qemuMigrateDisk(disk, nmigrate_disks, migrate_disks))
 continue;
 
+if (disk->src->readonly) {
+virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
+   _("Cannot migrate read-only disk %s"),
+   disk->dst);
+goto cleanup;
+}
+
 if (!(diskAlias = qemuAliasFromDisk(disk)) ||
 (virAsprintf(_dest, "nbd:%s:%d:exportname=%s",
  hoststr, port, diskAlias) < 0))
-- 
2.7.4

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

Re: [libvirt] [PATCH v1 0/4] libxl: channels support

[Joao Martins]

On 09/20/2016 01:14 PM, Michal Privoznik wrote:
> On 20.09.2016 13:57, Joao Martins wrote:
>> On 09/20/2016 11:54 AM, Michal Privoznik wrote:
>>> On 20.09.2016 12:43, Joao Martins wrote:
 On 09/20/2016 05:14 AM, Michal Privoznik wrote:
> On 20.09.2016 00:04, Jim Fehlig wrote:
>> On 09/16/2016 05:43 PM, Joao Martins wrote:
>>> Hey,
>>>
>>>  Additionally what does "state"
>>> signify for virtio case: is it that the guest agent is connected, or 
>>> that the
>>> virtio serial is connected? Looking at the qemu driver on
>>> processSerialChangedEvent it sounds to me like it's about the serial 
>>> state.
>>
>> AFAICT you are right, but perhaps Michal is kind enough to confirm. I 
>> think he
>> is familiar with this code.
>
> That attribute is put by libvirt into live XML so that mgmt apps can
> query for it. The attribute says whether the guest part of channel is
> opened by a process running within guest. In case of the qemu-ga whether
> we have the guest agent up & running. Whenever the guest end of a
> channel is opened/closed, qemu sends us an event so we can update our
> internal state and put the correct value when formatting live XML.
> Therefore, it makes no sense to make this attribute RW (meaning users
> could set it), obviously.
 Hmm if it refers to qemu agent actually (dis)connected from guest side it 
 might
 be difficult to provide the same "state" semantics in libxl driver at least
 without changes on the toolstack. If it referring to virtio-serial state we
 could easily do that by periodically calling libxl_channel_getinfo until 
 state
 is 4 (connected). But it's the actual agent process state as connected in 
 which
 case to have "state" attribute we would need to add similar to libxl event
 DOMAIN_CREATE_CONSOLE_AVAILABLE but instead referring to the guest channel.
>>>
>>> Well, in qemu it really just means that somebody is listening. Note that
>>> I say "somebody". That is if you kill qemu-ga in the guest and just 'cat
>>> /dev/virtio-ports/org.qemu-ga.' we will report state='connected' (or
>>> what's the path, and yes you can't use cat, but you get my point).
>> Yeap I understand. Looking at both libvirt, qemu  it looks like the event
>> allowing this is QMP event VSERPORT_CONNECTED|VSERPORT_DISCONNECTED on 
>> libvirt
>> commit 15bbaaf01 ("qemu: Add handling for VSERPORT_CHANGE event") and qemu
>> commit e2ae6159d ("virtio-serial: report frontend connection state via
>> monitor"). Looking at the frontend driver it has the granularity of sending 
>> port
>> open/close events (quite nice!), which I assume it's what qemu is using as 
>> info
>> to propagate these events to libvirt. Although this looks very specific to
>> virtio workings, which might not be possible to get the equivalent with the 
>> Xen
>> console. So perhaps having a periodical (with a timeout) guest-ping would be 
>> the
>> best course of action I guess?
> 
> Well, what we have used in the past (until having this fancy system of
> events) was that we just did not set the attribute at all (in fact it
> was introduced only after we've done our part of implementation).
> Moreover, we've sent 'guest-ping' to the guest agent just before trying
> to execute a real command. If ping timed out, we've error-ed out and did
> not execute the real command. This was to keep libvirt and qemu state in
> sync - the guest agent command might change the guest state.
> 
> I think xen can reuse this logic until future time when events are
> introduced to it too. And also, we don't need to expose the attribute
> for xen domains until then.
Cool, sounds good. BTW the first patch in this series, I think it goes like
you're suggesting: defining a new "xenTarget" in the schema whereas this
attribute is not included, plus avoiding the "state" attribute updates.

Joao

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

Re: [libvirt] [PATCH] virtlogd: Don't stop or restart along with libvirtd

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 03:29:59PM +0200, Andrea Bolognani wrote:
> Commit 839a060 tied the lifecycle of virtlogd more
> closely to that of libvirtd. Unfortunately, while starting
> virtlogd when libvirtd is started is definitely a good idea,
> restarting virtlogd or shutting it down at any time outside
> of system poweroff is not.
> 
> Revert part of that commit by removing the PartOf= lines,
> meaning that only startup requests will be propagated from
> libvirtd to virtlogd.
> 
> Resolves: https://bugzilla.redhat.com/1372576
> ---
>  src/logging/virtlogd.service.in | 1 -
>  src/logging/virtlogd.socket.in  | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/src/logging/virtlogd.service.in b/src/logging/virtlogd.service.in
> index 8287994..09e0740 100644
> --- a/src/logging/virtlogd.service.in
> +++ b/src/logging/virtlogd.service.in
> @@ -2,7 +2,6 @@
>  Description=Virtual machine log manager
>  Requires=virtlogd.socket
>  Before=libvirtd.service
> -PartOf=libvirtd.service
>  Documentation=man:virtlogd(8)
>  Documentation=http://libvirt.org
>  
> diff --git a/src/logging/virtlogd.socket.in b/src/logging/virtlogd.socket.in
> index efb6504..22b9360 100644
> --- a/src/logging/virtlogd.socket.in
> +++ b/src/logging/virtlogd.socket.in
> @@ -1,7 +1,6 @@
>  [Unit]
>  Description=Virtual machine log manager socket
>  Before=libvirtd.service
> -PartOf=libvirtd.service
>  
>  [Socket]
>  ListenStream=@localstatedir@/run/libvirt/virtlogd-sock

ACK

FYI, systemd docs say

   PartOf=
   Configures dependencies similar to Requires=, but limited to
   stopping and restarting of units. When systemd stops or restarts
   the units listed here, the action is propagated to this unit. Note
   that this is a one-way dependency — changes to this unit do not
   affect the listed units.

we clearly don't want 'restart' propagated to virtlogd
or virtlockd - those units must only ever 'reexec'
themselves.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

[libvirt] [PATCH] virtlogd: Don't stop or restart along with libvirtd

[Andrea Bolognani]

Commit 839a060 tied the lifecycle of virtlogd more
closely to that of libvirtd. Unfortunately, while starting
virtlogd when libvirtd is started is definitely a good idea,
restarting virtlogd or shutting it down at any time outside
of system poweroff is not.

Revert part of that commit by removing the PartOf= lines,
meaning that only startup requests will be propagated from
libvirtd to virtlogd.

Resolves: https://bugzilla.redhat.com/1372576
---
 src/logging/virtlogd.service.in | 1 -
 src/logging/virtlogd.socket.in  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/logging/virtlogd.service.in b/src/logging/virtlogd.service.in
index 8287994..09e0740 100644
--- a/src/logging/virtlogd.service.in
+++ b/src/logging/virtlogd.service.in
@@ -2,7 +2,6 @@
 Description=Virtual machine log manager
 Requires=virtlogd.socket
 Before=libvirtd.service
-PartOf=libvirtd.service
 Documentation=man:virtlogd(8)
 Documentation=http://libvirt.org
 
diff --git a/src/logging/virtlogd.socket.in b/src/logging/virtlogd.socket.in
index efb6504..22b9360 100644
--- a/src/logging/virtlogd.socket.in
+++ b/src/logging/virtlogd.socket.in
@@ -1,7 +1,6 @@
 [Unit]
 Description=Virtual machine log manager socket
 Before=libvirtd.service
-PartOf=libvirtd.service
 
 [Socket]
 ListenStream=@localstatedir@/run/libvirt/virtlogd-sock
-- 
2.7.4

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

Re: [libvirt] [PATCH v4 1/8] vsh: Enforce checking for missing help string

[Erik Skultety]

On 20/09/16 14:43, Ján Tomko wrote:
> On Mon, Sep 19, 2016 at 03:00:26PM +0200, Erik Skultety wrote:
>> The intention is to move vshCmddefCheckInternals out of
>> vshCmddefOptParse to
>> our test suite. First step to do that is to enforce checking for an
>> existing
>> help string (that also means it's non-empty) in a command because a
>> command
>> without a help is not much of a use.
>>
>> Signed-off-by: Erik Skultety 
>> ---
>> tools/vsh.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
> 
> ACK
> 
> Jan

Thanks, as I said in on of the latter patches, I adjusted the patches
according to your notes and pushed the series.

Erik

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

Re: [libvirt] xen/libvirt freeze while attching network-device to vm´s - question about provided patches

[Guido.Rossmueller]

Hi Jim,

thanks for your response ans sorry for my late answer,

i´m sorry, i don´t really understand what you are missing in [2], or from where 
in the log-output you see that an 
shutdown event is missing.

on our test-system the output looks normaly as follow:

2016-09-20 15:00:38 CEST libxl: debug: libxl.c:1719:devices_destroy_cb: forked 
pid 14987 for destroy of domain 1375
2016-09-20 15:00:38 CEST libxl: debug: libxl_event.c:576:watchfd_callback: 
watch w=0x7fe63c4b9180 wpath=@releaseDomain token=3/0: event 
epath=@releaseDomain
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1207:domain_death_xswatch_callback: [evg=0x7fe63c3ac070:0] nentries=200 
rc=14 0..1388
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c3ac070:0]   
got=domaininfos[0] got->domain=0
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0020
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c1564d0:1374]   
got=domaininfos[0] got->domain=0
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c1564d0:1374]   
got=domaininfos[1] got->domain=1374
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0022
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe67c0be740:1375]   
got=domaininfos[1] got->domain=1374
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe67c0be740:1375]   
got=domaininfos[2] got->domain=1376
2016-09-20 15:00:38 CEST libxl: debug: libxl.c:1163:domain_death_occurred: 
missing from list
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe67c0c4cd0:1376]   
got=domaininfos[2] got->domain=1376
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0012
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c4937e0:1378]   
got=domaininfos[2] got->domain=1376
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c4937e0:1378]   
got=domaininfos[3] got->domain=1378
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0012
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe68407e8d0:1379]   
got=domaininfos[3] got->domain=1378
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe68407e8d0:1379]   
got=domaininfos[4] got->domain=1379
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0012
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c497090:1380]   
got=domaininfos[4] got->domain=1379
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c497090:1380]   
got=domaininfos[5] got->domain=1380
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0012
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe6800c1bc0:1381]   
got=domaininfos[5] got->domain=1380
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe6800c1bc0:1381]   
got=domaininfos[6] got->domain=1381
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0012
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe6780a2c90:1382]   
got=domaininfos[6] got->domain=1381
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe6780a2c90:1382]   
got=domaininfos[7] got->domain=1382
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0022
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c4c5850:1383]   
got=domaininfos[7] got->domain=1382
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe63c4c5850:1383]   
got=domaininfos[8] got->domain=1383
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1245:domain_death_xswatch_callback:  exists shutdown_reported=0 
dominf.flags=0012
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe684080480:1384]   
got=domaininfos[8] got->domain=1383
2016-09-20 15:00:38 CEST libxl: debug: 
libxl.c:1218:domain_death_xswatch_callback: [evg=0x7fe684080480:1384]   
got=domaininfos[9] got->domain=1384
2016-09-20 15:00:38 CEST libxl: debug: 

Re: [libvirt] [PATCH v3 2/2] qemu_capabilities: Introduce gluster specific debug capability

[Prasanna Kalever]

On Tue, Sep 20, 2016 at 3:36 PM, Peter Krempa  wrote:
> On Tue, Sep 20, 2016 at 15:23:04 +0530, Prasanna Kumar Kalever wrote:
>> Teach qemu driver to detect whether qemu supports this configuration
>> factor or not.
>>
>> Signed-off-by: Prasanna Kumar Kalever 
>> ---
>>  src/qemu/qemu_capabilities.c |  6 ++
>>  src/qemu/qemu_capabilities.h |  3 +++
>>  src/qemu/qemu_command.c  | 13 -
>>  tests/qemuxml2argvtest.c |  3 ++-
>>  4 files changed, 19 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>> index c71b4dc..c4350d5 100644
>> --- a/src/qemu/qemu_capabilities.c
>> +++ b/src/qemu/qemu_capabilities.c
>> @@ -344,6 +344,8 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
>>"query-hotpluggable-cpus",
>>
>>"virtio-net.rx_queue_size", /* 235 */
>> +
>> +  "debug",  /* 236 */
>
> This is a VERY bad name for a feature flag. Also please follow the
> pattern in the file. It's 5 entries per block, very easy to spot.

Peter, I'm pretty bad at naming something, can either of you or Daniel
can please suggest one, that will be great.

Apologies, 5 block entry just missed my eyes or I might have overlooked at it.

>
>>  );
>>
>>
>> @@ -2496,6 +2498,10 @@ virQEMUCapsProbeQMPCommands(virQEMUCapsPtr qemuCaps,
>>  qemuMonitorSupportsActiveCommit(mon))
>>  virQEMUCapsSet(qemuCaps, QEMU_CAPS_ACTIVE_COMMIT);
>>
>> +/* Since qemu 2.7.0 */
>> +if (qemuCaps->version >= 2007000)
>> +virQEMUCapsSet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL);
>
> Version checks are bad. Is there anything you can base this on that can
> be detected? Version checks break with backports.

I don't think we have a better choice w.r.t checks ?

>
>> +
>>  return 0;
>>  }
>>
>> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
>> index 26ac1fa..ac9f4c8 100644
>> --- a/src/qemu/qemu_capabilities.h
>> +++ b/src/qemu/qemu_capabilities.h
>> @@ -379,6 +379,9 @@ typedef enum {
>>  /* 235 */
>>  QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE, /* virtio-net-*.rx_queue_size */
>>
>> +/* 236 */
>> +QEMU_CAPS_GLUSTER_DEBUG_LEVEL, /* -drive debug={0..9} */
>
> You are breaking the pattern.

Yeah, thank you!

>
>> +
>>  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 545e25d..ad0f1b2 100644
>> --- a/src/qemu/qemu_command.c
>> +++ b/src/qemu/qemu_command.c
>> @@ -1314,7 +1314,8 @@ qemuDiskBusNeedsDeviceArg(int bus)
>>
>>  static int
>>  qemuBuildDriveSourceStr(virDomainDiskDefPtr disk,
>> -virBufferPtr buf)
>> +virBufferPtr buf,
>> +  virQEMUCapsPtr qemuCaps)
>
> Misaligned.
>
>>  {
>>  int actualType = virStorageSourceGetActualType(disk->src);
>>  qemuDomainDiskPrivatePtr diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk);
>> @@ -1385,7 +1386,8 @@ qemuBuildDriveSourceStr(virDomainDiskDefPtr disk,
>>
>>  if (disk->src &&
>>  disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
>> -virBufferAsprintf(buf, "file.debug=%d,", disk->src->debug_level);
>> +if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL))
>> +virBufferAsprintf(buf, "file.debug=%d,", 
>> disk->src->debug_level);
>>  }
>>
>>  if (secinfo && secinfo->type == VIR_DOMAIN_SECRET_INFO_TYPE_AES) {
>> @@ -1513,7 +1515,7 @@ qemuBuildDriveStr(virDomainDiskDefPtr disk,
>>  break;
>>  }
>>
>> -if (qemuBuildDriveSourceStr(disk, ) < 0)
>> +if (qemuBuildDriveSourceStr(disk, , qemuCaps) < 0)
>>  goto error;
>>
>>  if (emitDeviceSyntax)
>> @@ -2263,8 +2265,9 @@ qemuBuildDiskDriveCommandLine(virCommandPtr cmd,
>>
>>  if (disk->src &&
>>  disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
>> -if (cfg->glusterDebugLevel)
>> -disk->src->debug_level = cfg->glusterDebugLevel;
>> +if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL) &&
>> +cfg->glusterDebugLevel)
>> +disk->src->debug_level = cfg->glusterDebugLevel;
>>  }
>>
>>  if (!(optstr = qemuBuildDriveStr(disk, driveBoot, qemuCaps)))
>> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
>> index dbb0e4d..b29a63b 100644
>> --- a/tests/qemuxml2argvtest.c
>> +++ b/tests/qemuxml2argvtest.c
>> @@ -832,7 +832,8 @@ mymain(void)
>>  DO_TEST("disk-drive-network-iscsi-lun",
>>  QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_VIRTIO_SCSI,
>>  QEMU_CAPS_SCSI_BLOCK);
>> -DO_TEST("disk-drive-network-gluster", NONE);
>> +DO_TEST("disk-drive-network-gluster",
>> +QEMU_CAPS_GLUSTER_DEBUG_LEVEL);
>
> This patch fails make check. You forgot to bundle in some changes.
>
> Peter

--
libvir-list mailing list
libvir-list@redhat.com

Re: [libvirt] [RFC PATCH] Use disable-modern=on for disk device='lun'

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 02:21:49PM +0200, Ján Tomko wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1365823
> 
> For virtio-blk, scsi=on has been deprecated in virtio-1,
> so  no longer works with
> with a virtio-blk-pci device with machine types newer than 2.7:
> https://bugzilla.redhat.com/show_bug.cgi?id=1245453
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9a4c0e22
> 
> Add disable-modern=on on the QEMU command line to prolong
> the suffering for a while longer.
> ---
> The alternative would be using the QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY
> capability to report an error, instead of waiting until QEMU fails with
> an error, since it's the first commit when the following error should
> be reachable via libvirt-generated command line:
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=efb8206c

My preference would be for us to come to some conclusion of the
way we will represent disable-modern/disable-legacy in the
XML before we try to fix this device=lun problem.

In general I'm not a fan of silently changing configs behind
the users back. IOW, if we have XML for setting disable-modern
explicitly, then I would not want to see us silently setting
disable-modern ourselves. Leave it upto the app to decide to
set it if they really want to continue using virtio-blk instead
of virtio-scsi.

>  src/qemu/qemu_command.c| 12 +
>  .../qemuxml2argv-virtio-lun-legacy.args| 30 +
>  .../qemuxml2argv-virtio-lun-legacy.xml | 52 
> ++
>  tests/qemuxml2argvtest.c   |  3 ++
>  4 files changed, 97 insertions(+)
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-lun-legacy.args
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-lun-legacy.xml
> 
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 051a0bc..03dc20e 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -2075,6 +2075,18 @@ qemuBuildDriveDevStr(const virDomainDef *def,
>  virBufferAddLit(, "virtio-blk-pci");
>  if (disk->iothread)
>  virBufferAsprintf(, ",iothread=iothread%u", 
> disk->iothread);
> +
> +/*
> + * SCSI command passthrough was deprecated in virtio 1.0,
> + * see https://bugzilla.redhat.com/show_bug.cgi?id=1365823
> + */
> +if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SCSI) &&
> +disk->device == VIR_DOMAIN_DISK_DEVICE_LUN &&
> +virQEMUCapsGet(qemuCaps, 
> QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY)) {
> +VIR_WARN("lun type devices are deprecated for virtio-blk-pci 
> devices, "
> + "consider using disks on a virtio-scsi controller");

Adding warnings like this is fairly pointless since they've invisible to the
person who actually needs to see them (the app developer), and annoying to
the person who does see them (the host administrator).

> +virBufferAddLit(, ",disable-modern=on");
> +}
>  }

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [PATCH v7 2/5] conf: Introduce {default|chardev}_tls_x509_secret_uuid

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 08:26:55AM -0400, John Ferlan wrote:
> 
> 
> On 09/19/2016 10:53 AM, Daniel P. Berrange wrote:
> > On Mon, Sep 19, 2016 at 10:39:21AM -0400, John Ferlan wrote:
> >> Add a new qemu.conf variables to store the UUID for the secret that could
> >> be used to present credentials to access the TLS chardev.  Since this will
> >> be a server level and it's possible to use some sort of default, introduce
> >> both the default and chardev logic at the same time making the setting of
> >> the chardev check for it's own value, then if not present checking whether
> >> the default value had been set.
> >>
> >> The chardevTLSx509haveUUID bool will be used as the marker for whether
> >> the chardevTLSx509secretUUID was successfully read. In the future this
> >> is how it'd determined whether to add the secret object for a TLS object.
> >>
> >> Signed-off-by: John Ferlan 
> >> ---
> >>  src/qemu/libvirtd_qemu.aug |  2 ++
> >>  src/qemu/qemu.conf | 24 
> >>  src/qemu/qemu_conf.c   | 22 ++
> >>  src/qemu/qemu_conf.h   |  3 +++
> >>  src/qemu/test_libvirtd_qemu.aug.in |  2 ++
> >>  5 files changed, 53 insertions(+)
> >>
> >> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
> >> index 988201e..73ebeda 100644
> >> --- a/src/qemu/libvirtd_qemu.aug
> >> +++ b/src/qemu/libvirtd_qemu.aug
> >> @@ -29,6 +29,7 @@ module Libvirtd_qemu =
> >> (* Config entry grouped by function - same order as example config *)
> >> let default_tls_entry = str_entry "default_tls_x509_cert_dir"
> >>   | bool_entry "default_tls_x509_verify"
> >> + | str_entry "default_tls_x509_secret_uuid"
> >>  
> >> let vnc_entry = str_entry "vnc_listen"
> >>   | bool_entry "vnc_auto_unix_socket"
> >> @@ -51,6 +52,7 @@ module Libvirtd_qemu =
> >> let chardev_entry = bool_entry "chardev_tls"
> >>   | str_entry "chardev_tls_x509_cert_dir"
> >>   | bool_entry "chardev_tls_x509_verify"
> >> + | str_entry "chardev_tls_x509_secret_uuid"
> >>  
> >> let nogfx_entry = bool_entry "nographics_allow_host_audio"
> >>  
> >> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> >> index e4c2aae..7114fa1 100644
> >> --- a/src/qemu/qemu.conf
> >> +++ b/src/qemu/qemu.conf
> >> @@ -28,6 +28,20 @@
> >>  #
> >>  #default_tls_x509_verify = 1
> >>  
> >> +#
> >> +# In order to provide a password to unlock the private key to be used
> >> +# in order to provide the TLS credentials, a libvirt secret will need
> >> +# to be created and then the UUID of that secret added as a configuration
> >> +# parameter. See the libvirt documentation for specific details regarding
> >> +# how to create a "tls" secret type.
> >> +#
> >> +# NB This default all-zeros UUID will not work. Replace it with the
> >> +# output from the UUID for the TLS secret from a 'virsh secret-list'
> >> +# command and then uncomment the entry
> >> +#
> >> +#default_tls_x509_secret_uuid = "----"
> > 
> > We could perhaps be a little more explicit about the fact that when
> > this is commented out, the private key is required to be in
> > non-encrypted PEM format.
> > 
> 
> Fair enough - a simple enough addition, so at the end of the first
> paragraph (and repeated again for chardev_tls_x509_secret_uuid), how about:
> 
> " A libvirt secret requires usage of a non-encrypted PEM format
> certificate."
> 
> Or is there some other wording that is preferable?

Something like this:

  "Libvirt assumes the server-key.pem file is unencrypted by default.
   To use an encrypted server-key.pem file, the password to decrypt
   the PEM file is requird. This can be provided by creating a secret
   object in libvirt and then uncommenting this setting to set the
   UUID of the secret"

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [libvirt] [PATCH v4 1/8] vsh: Enforce checking for missing help string

[Ján Tomko]

On Mon, Sep 19, 2016 at 03:00:26PM +0200, Erik Skultety wrote:

The intention is to move vshCmddefCheckInternals out of vshCmddefOptParse to
our test suite. First step to do that is to enforce checking for an existing
help string (that also means it's non-empty) in a command because a command
without a help is not much of a use.

Signed-off-by: Erik Skultety 
---
tools/vsh.c | 5 +
1 file changed, 5 insertions(+)



ACK

Jan


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

Re: [libvirt] [PATCH v7 2/5] conf: Introduce {default|chardev}_tls_x509_secret_uuid

[John Ferlan]

On 09/19/2016 10:53 AM, Daniel P. Berrange wrote:
> On Mon, Sep 19, 2016 at 10:39:21AM -0400, John Ferlan wrote:
>> Add a new qemu.conf variables to store the UUID for the secret that could
>> be used to present credentials to access the TLS chardev.  Since this will
>> be a server level and it's possible to use some sort of default, introduce
>> both the default and chardev logic at the same time making the setting of
>> the chardev check for it's own value, then if not present checking whether
>> the default value had been set.
>>
>> The chardevTLSx509haveUUID bool will be used as the marker for whether
>> the chardevTLSx509secretUUID was successfully read. In the future this
>> is how it'd determined whether to add the secret object for a TLS object.
>>
>> Signed-off-by: John Ferlan 
>> ---
>>  src/qemu/libvirtd_qemu.aug |  2 ++
>>  src/qemu/qemu.conf | 24 
>>  src/qemu/qemu_conf.c   | 22 ++
>>  src/qemu/qemu_conf.h   |  3 +++
>>  src/qemu/test_libvirtd_qemu.aug.in |  2 ++
>>  5 files changed, 53 insertions(+)
>>
>> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
>> index 988201e..73ebeda 100644
>> --- a/src/qemu/libvirtd_qemu.aug
>> +++ b/src/qemu/libvirtd_qemu.aug
>> @@ -29,6 +29,7 @@ module Libvirtd_qemu =
>> (* Config entry grouped by function - same order as example config *)
>> let default_tls_entry = str_entry "default_tls_x509_cert_dir"
>>   | bool_entry "default_tls_x509_verify"
>> + | str_entry "default_tls_x509_secret_uuid"
>>  
>> let vnc_entry = str_entry "vnc_listen"
>>   | bool_entry "vnc_auto_unix_socket"
>> @@ -51,6 +52,7 @@ module Libvirtd_qemu =
>> let chardev_entry = bool_entry "chardev_tls"
>>   | str_entry "chardev_tls_x509_cert_dir"
>>   | bool_entry "chardev_tls_x509_verify"
>> + | str_entry "chardev_tls_x509_secret_uuid"
>>  
>> let nogfx_entry = bool_entry "nographics_allow_host_audio"
>>  
>> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
>> index e4c2aae..7114fa1 100644
>> --- a/src/qemu/qemu.conf
>> +++ b/src/qemu/qemu.conf
>> @@ -28,6 +28,20 @@
>>  #
>>  #default_tls_x509_verify = 1
>>  
>> +#
>> +# In order to provide a password to unlock the private key to be used
>> +# in order to provide the TLS credentials, a libvirt secret will need
>> +# to be created and then the UUID of that secret added as a configuration
>> +# parameter. See the libvirt documentation for specific details regarding
>> +# how to create a "tls" secret type.
>> +#
>> +# NB This default all-zeros UUID will not work. Replace it with the
>> +# output from the UUID for the TLS secret from a 'virsh secret-list'
>> +# command and then uncomment the entry
>> +#
>> +#default_tls_x509_secret_uuid = "----"
> 
> We could perhaps be a little more explicit about the fact that when
> this is commented out, the private key is required to be in
> non-encrypted PEM format.
> 

Fair enough - a simple enough addition, so at the end of the first
paragraph (and repeated again for chardev_tls_x509_secret_uuid), how about:

" A libvirt secret requires usage of a non-encrypted PEM format
certificate."

Or is there some other wording that is preferable?

Tks -

John

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

Re: [libvirt] [PATCH v1 0/4] libxl: channels support

[Michal Privoznik]

On 20.09.2016 13:57, Joao Martins wrote:
> On 09/20/2016 11:54 AM, Michal Privoznik wrote:
>> On 20.09.2016 12:43, Joao Martins wrote:
>>> On 09/20/2016 05:14 AM, Michal Privoznik wrote:
 On 20.09.2016 00:04, Jim Fehlig wrote:
> On 09/16/2016 05:43 PM, Joao Martins wrote:
>> Hey,
>>
>>  Additionally what does "state"
>> signify for virtio case: is it that the guest agent is connected, or 
>> that the
>> virtio serial is connected? Looking at the qemu driver on
>> processSerialChangedEvent it sounds to me like it's about the serial 
>> state.
>
> AFAICT you are right, but perhaps Michal is kind enough to confirm. I 
> think he
> is familiar with this code.

 That attribute is put by libvirt into live XML so that mgmt apps can
 query for it. The attribute says whether the guest part of channel is
 opened by a process running within guest. In case of the qemu-ga whether
 we have the guest agent up & running. Whenever the guest end of a
 channel is opened/closed, qemu sends us an event so we can update our
 internal state and put the correct value when formatting live XML.
 Therefore, it makes no sense to make this attribute RW (meaning users
 could set it), obviously.
>>> Hmm if it refers to qemu agent actually (dis)connected from guest side it 
>>> might
>>> be difficult to provide the same "state" semantics in libxl driver at least
>>> without changes on the toolstack. If it referring to virtio-serial state we
>>> could easily do that by periodically calling libxl_channel_getinfo until 
>>> state
>>> is 4 (connected). But it's the actual agent process state as connected in 
>>> which
>>> case to have "state" attribute we would need to add similar to libxl event
>>> DOMAIN_CREATE_CONSOLE_AVAILABLE but instead referring to the guest channel.
>>
>> Well, in qemu it really just means that somebody is listening. Note that
>> I say "somebody". That is if you kill qemu-ga in the guest and just 'cat
>> /dev/virtio-ports/org.qemu-ga.' we will report state='connected' (or
>> what's the path, and yes you can't use cat, but you get my point).
> Yeap I understand. Looking at both libvirt, qemu  it looks like the event
> allowing this is QMP event VSERPORT_CONNECTED|VSERPORT_DISCONNECTED on libvirt
> commit 15bbaaf01 ("qemu: Add handling for VSERPORT_CHANGE event") and qemu
> commit e2ae6159d ("virtio-serial: report frontend connection state via
> monitor"). Looking at the frontend driver it has the granularity of sending 
> port
> open/close events (quite nice!), which I assume it's what qemu is using as 
> info
> to propagate these events to libvirt. Although this looks very specific to
> virtio workings, which might not be possible to get the equivalent with the 
> Xen
> console. So perhaps having a periodical (with a timeout) guest-ping would be 
> the
> best course of action I guess?

Well, what we have used in the past (until having this fancy system of
events) was that we just did not set the attribute at all (in fact it
was introduced only after we've done our part of implementation).
Moreover, we've sent 'guest-ping' to the guest agent just before trying
to execute a real command. If ping timed out, we've error-ed out and did
not execute the real command. This was to keep libvirt and qemu state in
sync - the guest agent command might change the guest state.

I think xen can reuse this logic until future time when events are
introduced to it too. And also, we don't need to expose the attribute
for xen domains until then.

Michal

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

[libvirt] [PATCH] Add missing 'extern' for VIR_EXPORT_VAR macro

[Daniel P. Berrange]

The recent update to gnulib

  commit 9d7a37ecb2ab516c19164a57b8aeb32016a99d2c
  Author: Eric Blake 
  Date:   Thu Sep 15 15:12:52 2016 -0500

build: update to latest gnulib

Pulled in a change that adds -fno-common to the default compiler
flags

  commit bf8e658ffadb95d444f56d222d04c9af955af765
  Author: Jim Meyering 
  Date:   Fri Sep 2 09:16:16 2016 -0700

manywarnings: add -fno-common

This caused libvirt Mingw build to break with the compiler
reporting 100's of definitions of virConnectAuthPtrDefault

./.libs/libvirt_util.a(libvirt_util_la-virarch.o):virarch.c:(.bss+0x0): 
multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):viralloc.c:(.bss+0x0): first 
defined here
./.libs/libvirt_util.a(libvirt_util_la-viratomic.o):viratomic.c:(.bss+0x0): 
multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87:
 first defined here
./.libs/libvirt_util.a(libvirt_util_la-viraudit.o):viraudit.c:(.bss+0x0): 
multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87:
 first defined here
./.libs/libvirt_util.a(libvirt_util_la-virauth.o):virauth.c:(.bss+0x0): 
multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87:
 first defined here
./.libs/libvirt_util.a(libvirt_util_la-virauthconfig.o):virauthconfig.c:(.bss+0x0):
 multiple definition of `virConnectAuthPtrDefault'
...snip...

The cause is our VIR_EXPORT_VAR macro which has some
magic on win to add dllexport/dllimport to the variable
declaration. Unfortunately the dllexport branch missed
off the 'extern' keyword, so the header file was in
fact declaring an instance of the variable in every
source file.

Previously the linker would merge all these definitions
into one, but that no longer happens due to -fno-common

Signed-off-by: Daniel P. Berrange 
---

Pushing as a CI build fix

 include/libvirt/libvirt-common.h.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/libvirt/libvirt-common.h.in 
b/include/libvirt/libvirt-common.h.in
index 79bfe90..0e8ada4 100644
--- a/include/libvirt/libvirt-common.h.in
+++ b/include/libvirt/libvirt-common.h.in
@@ -49,7 +49,7 @@ extern "C" {
 #   define VIR_EXPORT_VAR extern
 #  else
 #   ifdef IN_LIBVIRT
-#define VIR_EXPORT_VAR __declspec(dllexport)
+#define VIR_EXPORT_VAR __declspec(dllexport) extern
 #   else
 #define VIR_EXPORT_VAR __declspec(dllimport) extern
 #   endif
-- 
2.7.4

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

Re: [libvirt] [PATCH v1 0/4] libxl: channels support

[Joao Martins]

On 09/20/2016 11:54 AM, Michal Privoznik wrote:
> On 20.09.2016 12:43, Joao Martins wrote:
>> On 09/20/2016 05:14 AM, Michal Privoznik wrote:
>>> On 20.09.2016 00:04, Jim Fehlig wrote:
 On 09/16/2016 05:43 PM, Joao Martins wrote:
> Hey,
>
>  Additionally what does "state"
> signify for virtio case: is it that the guest agent is connected, or that 
> the
> virtio serial is connected? Looking at the qemu driver on
> processSerialChangedEvent it sounds to me like it's about the serial 
> state.

 AFAICT you are right, but perhaps Michal is kind enough to confirm. I 
 think he
 is familiar with this code.
>>>
>>> That attribute is put by libvirt into live XML so that mgmt apps can
>>> query for it. The attribute says whether the guest part of channel is
>>> opened by a process running within guest. In case of the qemu-ga whether
>>> we have the guest agent up & running. Whenever the guest end of a
>>> channel is opened/closed, qemu sends us an event so we can update our
>>> internal state and put the correct value when formatting live XML.
>>> Therefore, it makes no sense to make this attribute RW (meaning users
>>> could set it), obviously.
>> Hmm if it refers to qemu agent actually (dis)connected from guest side it 
>> might
>> be difficult to provide the same "state" semantics in libxl driver at least
>> without changes on the toolstack. If it referring to virtio-serial state we
>> could easily do that by periodically calling libxl_channel_getinfo until 
>> state
>> is 4 (connected). But it's the actual agent process state as connected in 
>> which
>> case to have "state" attribute we would need to add similar to libxl event
>> DOMAIN_CREATE_CONSOLE_AVAILABLE but instead referring to the guest channel.
> 
> Well, in qemu it really just means that somebody is listening. Note that
> I say "somebody". That is if you kill qemu-ga in the guest and just 'cat
> /dev/virtio-ports/org.qemu-ga.' we will report state='connected' (or
> what's the path, and yes you can't use cat, but you get my point).
Yeap I understand. Looking at both libvirt, qemu  it looks like the event
allowing this is QMP event VSERPORT_CONNECTED|VSERPORT_DISCONNECTED on libvirt
commit 15bbaaf01 ("qemu: Add handling for VSERPORT_CHANGE event") and qemu
commit e2ae6159d ("virtio-serial: report frontend connection state via
monitor"). Looking at the frontend driver it has the granularity of sending port
open/close events (quite nice!), which I assume it's what qemu is using as info
to propagate these events to libvirt. Although this looks very specific to
virtio workings, which might not be possible to get the equivalent with the Xen
console. So perhaps having a periodical (with a timeout) guest-ping would be the
best course of action I guess?

> We don't do any checks whether it is actual qemu-ga listening. Moreover, we
> report that for all the channels, not just the one used by the guest
> agent. So it really means that there is somebody listening in the guest.
Yeap that's what I understood from your comment. I mentioned qemu aguest agent
also as an example.

Thanks for the clarifications!
Joao

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

Re: [libvirt] [PATCH v1 0/4] libxl: channels support

[Michal Privoznik]

On 20.09.2016 12:43, Joao Martins wrote:
> On 09/20/2016 05:14 AM, Michal Privoznik wrote:
>> On 20.09.2016 00:04, Jim Fehlig wrote:
>>> On 09/16/2016 05:43 PM, Joao Martins wrote:
 Hey,


  Additionally what does "state"
 signify for virtio case: is it that the guest agent is connected, or that 
 the
 virtio serial is connected? Looking at the qemu driver on
 processSerialChangedEvent it sounds to me like it's about the serial state.
>>>
>>> AFAICT you are right, but perhaps Michal is kind enough to confirm. I think 
>>> he
>>> is familiar with this code.
>>
>> That attribute is put by libvirt into live XML so that mgmt apps can
>> query for it. The attribute says whether the guest part of channel is
>> opened by a process running within guest. In case of the qemu-ga whether
>> we have the guest agent up & running. Whenever the guest end of a
>> channel is opened/closed, qemu sends us an event so we can update our
>> internal state and put the correct value when formatting live XML.
>> Therefore, it makes no sense to make this attribute RW (meaning users
>> could set it), obviously.
> Hmm if it refers to qemu agent actually (dis)connected from guest side it 
> might
> be difficult to provide the same "state" semantics in libxl driver at least
> without changes on the toolstack. If it referring to virtio-serial state we
> could easily do that by periodically calling libxl_channel_getinfo until state
> is 4 (connected). But it's the actual agent process state as connected in 
> which
> case to have "state" attribute we would need to add similar to libxl event
> DOMAIN_CREATE_CONSOLE_AVAILABLE but instead referring to the guest channel.

Well, in qemu it really just means that somebody is listening. Note that
I say "somebody". That is if you kill qemu-ga in the guest and just 'cat
/dev/virtio-ports/org.qemu-ga.' we will report state='connected' (or
what's the path, and yes you can't use cat, but you get my point). We
don't do any checks whether it is actual qemu-ga listening. Moreover, we
report that for all the channels, not just the one used by the guest
agent. So it really means that there is somebody listening in the guest.

Michal

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

Re: [libvirt] [PATCH v1 2/4] libxl: channels support

[Joao Martins]

On 09/19/2016 11:57 PM, Jim Fehlig wrote:
> On 09/16/2016 05:43 PM, Joao Martins wrote:
>> And allow libxl to handle channel element which creates a Xen
>> console visible to the guest as a low-bandwitdh communication
>> channel. If type is PTY we also fetch the tty after boot using
>> libxl_channel_getinfo to fetch the tty path.  Since support for
>> libxl channels only came on Xen >= 4.5 we therefore need to
>> conditionally compile it with LIBXL_HAVE_DEVICE_CHANNEL.
>>
>> After this patch and having a qemu guest agent:
>>  $ cat domain.xml | grep -a1 channel | head -n 5 | tail -n 4
>>  
>>
>>
>>  
>>
>>  $ virsh create domain.xml
>>  $ echo '{"execute":"guest-network-get-interfaces"}' | socat
>>  stdio,ignoreeof  unix-connect:/tmp/channel
>>
>>  {"execute":"guest-network-get-interfaces"}
>>  {"return": [{"name": "lo", "ip-addresses": [{"ip-address-type": "ipv4",
>>  "ip-address": "127.0.0.1", "prefix": 8}, {"ip-address-type": "ipv6",
>>  "ip-address": "::1", "prefix": 128}], "hardware-address":
>>  "00:00:00:00:00:00"}, {"name": "eth0", "ip-addresses":
>>  [{"ip-address-type": "ipv4", "ip-address": "10.100.0.6", "prefix": 24},
>>  {"ip-address-type": "ipv6", "ip-address": "fe80::216:3eff:fe40:88eb",
>>  "prefix": 64}], "hardware-address": "00:16:3e:40:88:eb"}, {"name":
>>  "sit0"}]}
>>
>> Signed-off-by: Joao Martins 
>> ---
>>
>> NB: Should path be autogenerated if not included?
>> ---
>>  src/libxl/libxl_conf.c   | 90 
>> 
>>  src/libxl/libxl_domain.c | 41 ++
>>  2 files changed, 131 insertions(+)
>>
>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>> index 306e441..6fe0fa0 100644
>> --- a/src/libxl/libxl_conf.c
>> +++ b/src/libxl/libxl_conf.c
>> @@ -1490,6 +1490,91 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr 
>> cfg,
>>  
>>  }
>>  
>> +#ifdef LIBXL_HAVE_DEVICE_CHANNEL
>> +static int
>> +libxlMakeChannel(virDomainChrDefPtr l_channel,
>> + libxl_device_channel *x_channel)
>> +{
>> +int ret = -1;
>> +
>> +libxl_device_channel_init(x_channel);
>> +
>> +switch (l_channel->source.type) {
>> +case VIR_DOMAIN_CHR_TYPE_PTY:
>> +x_channel->connection = LIBXL_CHANNEL_CONNECTION_PTY;
>> +break;
>> +case VIR_DOMAIN_CHR_TYPE_UNIX:
>> +x_channel->connection = LIBXL_CHANNEL_CONNECTION_SOCKET;
>> +if (!l_channel->source.data.nix.path) {
>> +virReportError(VIR_ERR_OPERATION_INVALID, "%s",
>> +   _("channel path missing for unix type"));
>> +return ret;
>> +}
> 
> Will need to change if, as we think, a missing source path should be auto 
> generated.
Yeap, will change this.

> 
>> +if (VIR_STRDUP(x_channel->u.socket.path,
>> +   l_channel->source.data.nix.path) < 0)
>> +return ret;
>> +break;
>> +default:
>> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
>> +   _("channel source type not supported"));
>> +break;
>> +}
>> +
>> +switch (l_channel->targetType) {
>> +case VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN:
>> +if (!l_channel->target.name) {
>> +virReportError(VIR_ERR_OPERATION_INVALID, "%s",
>> +   _("channel target name missing"));
>> +return ret;
>> +}
>> +if (VIR_STRDUP(x_channel->name, l_channel->target.name) < 0)
>> +return ret;
>> +ret = 0;
>> +break;
>> +default:
>> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
>> +   _("channel target type not supported"));
>> +break;
>> +}
> 
> IMO we can check for targetType ==  VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN on
> entry to this function and do away with the switch statement.
Indeed, it's definitely clearer.

> 
>> +
>> +return ret;
>> +}
>> +
>> +static int
>> +libxlMakeChannelList(virDomainDefPtr def, libxl_domain_config *d_config)
>> +{
>> +virDomainChrDefPtr *l_channels = def->channels;
>> +size_t nchannels = def->nchannels;
>> +libxl_device_channel *x_channels;
>> +size_t i, nvchannels = 0;
>> +
>> +if (VIR_ALLOC_N(x_channels, nchannels) < 0)
>> +return -1;
>> +
>> +for (i = 0; i < nchannels; i++) {
>> +if (l_channels[i]->deviceType != VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL)
>> +continue;
>> +
>> +if (libxlMakeChannel(l_channels[i], _channels[nvchannels]) < 0)
>> +goto error;
>> +
>> +nvchannels++;
>> +}
>> +
>> +VIR_SHRINK_N(x_channels, nchannels, nchannels - nvchannels);
>> +d_config->channels = x_channels;
>> +d_config->num_channels = nvchannels;
>> +
>> +return 0;
>> +
>> + error:
>> +for (i = 0; i < nchannels; i++)
>> +libxl_device_channel_dispose(_channels[i]);
>> +VIR_FREE(x_channels);
>> +return -1;
>> +}
>> +#endif
>> +
>>  #ifdef 

Re: [libvirt] [PATCH v1 0/4] libxl: channels support

[Joao Martins]

On 09/20/2016 05:14 AM, Michal Privoznik wrote:
> On 20.09.2016 00:04, Jim Fehlig wrote:
>> On 09/16/2016 05:43 PM, Joao Martins wrote:
>>> Hey,
>>>
>>> Channels have been on xen toolstack since Xen 4.5 and this small series
>>> adds support for it, including xenconfig conversion and appropriate tests.
>>
>> Cool! Thanks.
>>
>>> After this series it's possible to do this:
>>> (assuming correct configuration of qemu agent in the guest)
>>>
>>>  $ cat domain.xml | grep -a1 channel | head -n 5 | tail -n 4
>>>  
>>>
>>>
>>>  
>>>
>>>  $ virsh create domain.xml
>>>  $ echo '{"execute":"guest-network-get-interfaces"}' | socat
>>>  stdio,ignoreeof  unix-connect:/tmp/channel
>>>
>>>  {"execute":"guest-network-get-interfaces"}
>>>  {"return": [{"name": "lo", "ip-addresses": [{"ip-address-type": "ipv4",
>>>  "ip-address": "127.0.0.1", "prefix": 8}, {"ip-address-type": "ipv6",
>>>  "ip-address": "::1", "prefix": 128}], "hardware-address":
>>>  "00:00:00:00:00:00"}, {"name": "eth0", "ip-addresses":
>>>  [{"ip-address-type": "ipv4", "ip-address": "10.100.0.6", "prefix": 24},
>>>  {"ip-address-type": "ipv6", "ip-address": "fe80::216:3eff:fe40:88eb",
>>>  "prefix": 64}], "hardware-address": "00:16:3e:40:88:eb"}, {"name":
>>>  "sit0"}]}
> 
> BTW: libvirt has an API for this too - virDomainInterfaceAddresses in
> case you'd like to take the extra step :-).
> 
Indeed, I have that implemented already for guest agent integration series
mentioned further below :)

>>>
>>> There is just one thing unclear: is source "path" meant to be auto-generated
>>> if it's not specified in the channel config?
>>
>> I think so. According to docs/formatdomain.html
>>
>> Moreover, since 1.0.6 it is possible to have source path auto generated for
>> virtio unix channels. This is very useful in case of a qemu guest agent, 
>> where
>> users don't usually care about the source path since it's libvirt who talks 
>> to
>> the guest agent. In case users want to utilize this feature, they should 
>> leave
>>  element out.
I see.

> 
> Correct. Historically, we required users to provide us a path that host
> side of the channel is supposed to be listening at. But it wasn't very
> user-friendly feature lets say. So we wrote some code that generates the
> path automatically when needed. qemuDomainPrepareChannel() and
> qemuProcessPrepareMonitorChr().
OK. I will update it to auto-generate the path if not specified.

>>>  Additionally what does "state"
>>> signify for virtio case: is it that the guest agent is connected, or that 
>>> the
>>> virtio serial is connected? Looking at the qemu driver on
>>> processSerialChangedEvent it sounds to me like it's about the serial state.
>>
>> AFAICT you are right, but perhaps Michal is kind enough to confirm. I think 
>> he
>> is familiar with this code.
> 
> That attribute is put by libvirt into live XML so that mgmt apps can
> query for it. The attribute says whether the guest part of channel is
> opened by a process running within guest. In case of the qemu-ga whether
> we have the guest agent up & running. Whenever the guest end of a
> channel is opened/closed, qemu sends us an event so we can update our
> internal state and put the correct value when formatting live XML.
> Therefore, it makes no sense to make this attribute RW (meaning users
> could set it), obviously.
Hmm if it refers to qemu agent actually (dis)connected from guest side it might
be difficult to provide the same "state" semantics in libxl driver at least
without changes on the toolstack. If it referring to virtio-serial state we
could easily do that by periodically calling libxl_channel_getinfo until state
is 4 (connected). But it's the actual agent process state as connected in which
case to have "state" attribute we would need to add similar to libxl event
DOMAIN_CREATE_CONSOLE_AVAILABLE but instead referring to the guest channel.

>>> I also have one other series that lets us share the qemu agent across both 
>>> qemu
>>> and libxl drivers, with qemu-agent-command implemented. But it's still in an
>>> early stage.
> 
> Ah, that would be very nice indeed. We don't like copying code around.
Yeap :)

Cheers,
Joao

> 
>>>
>>> Any comments or feedback is appreciated :)
>>
>> Thanks again. I'll start reviewing the individual patches.
>>
>> Regards,
>> Jim
>>
> 
> Michal
> 

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

Re: [libvirt] [PATCH v3 1/2] qemu/gluster: add option for tuning debug logging level

[Peter Krempa]

On Tue, Sep 20, 2016 at 15:23:03 +0530, Prasanna Kumar Kalever wrote:
> This helps in selecting log level of the gluster gfapi, output to stderr.
> The option is 'gluster_debug_level', can be tuned by editing
> '/etc/libvirt/qemu.conf'
> 
> Debug levels ranges 0-9, with 9 being the most verbose, and 0 representing
> no debugging output.  The default is the same as it was before, which
> is a level of 4.  The current logging levels defined in the gluster
> gfapi are:
> 
> 0 - None
> 1 - Emergency
> 2 - Alert
> 3 - Critical
> 4 - Error
> 5 - Warning
> 6 - Notice
> 7 - Info
> 8 - Debug
> 9 - Trace
> 
> Signed-off-by: Prasanna Kumar Kalever 
> ---
>  src/qemu/libvirtd_qemu.aug   |  3 +++
>  src/qemu/qemu.conf   | 20 
> 
>  src/qemu/qemu_command.c  | 14 +-
>  src/qemu/qemu_conf.c |  3 +++
>  src/qemu/qemu_conf.h |  1 +
>  src/util/virstoragefile.h|  2 ++
>  .../qemuargv2xml-disk-drive-network-gluster.args |  7 ---
>  .../qemuxml2argv-disk-drive-network-gluster.args | 12 ++--
>  8 files changed, 52 insertions(+), 10 deletions(-)
> 
> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
> index 988201e..bdeaeef 100644
> --- a/src/qemu/libvirtd_qemu.aug
> +++ b/src/qemu/libvirtd_qemu.aug
> @@ -104,6 +104,8 @@ module Libvirtd_qemu =
>  
> let nvram_entry = str_array_entry "nvram"
>  
> +   let debug = int_entry "gluster_debug_level"

This is a too common name.

> +
> (* Each entry in the config is one of the following ... *)
> let entry = default_tls_entry
>   | vnc_entry
> @@ -119,6 +121,7 @@ module Libvirtd_qemu =
>   | network_entry
>   | log_entry
>   | nvram_entry
> + | debug
>  
> let comment = [ label "#comment" . del /#[ \t]*/ "# " .  store /([^ 
> \t\n][^\n]*)?/ . del /\n/ "\n" ]
> let empty = [ label "#empty" . eol ]

The rest looks now good to me. Since the second patch has too many
problems you can respin the name as well.

Peter

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

Re: [libvirt] [PATCH v3 2/2] qemu_capabilities: Introduce gluster specific debug capability

[Peter Krempa]

On Tue, Sep 20, 2016 at 15:23:04 +0530, Prasanna Kumar Kalever wrote:
> Teach qemu driver to detect whether qemu supports this configuration
> factor or not.
> 
> Signed-off-by: Prasanna Kumar Kalever 
> ---
>  src/qemu/qemu_capabilities.c |  6 ++
>  src/qemu/qemu_capabilities.h |  3 +++
>  src/qemu/qemu_command.c  | 13 -
>  tests/qemuxml2argvtest.c |  3 ++-
>  4 files changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index c71b4dc..c4350d5 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -344,6 +344,8 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
>"query-hotpluggable-cpus",
>  
>"virtio-net.rx_queue_size", /* 235 */
> +
> +  "debug",  /* 236 */

This is a VERY bad name for a feature flag. Also please follow the
pattern in the file. It's 5 entries per block, very easy to spot.

>  );
>  
>  
> @@ -2496,6 +2498,10 @@ virQEMUCapsProbeQMPCommands(virQEMUCapsPtr qemuCaps,
>  qemuMonitorSupportsActiveCommit(mon))
>  virQEMUCapsSet(qemuCaps, QEMU_CAPS_ACTIVE_COMMIT);
>  
> +/* Since qemu 2.7.0 */
> +if (qemuCaps->version >= 2007000)
> +virQEMUCapsSet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL);

Version checks are bad. Is there anything you can base this on that can
be detected? Version checks break with backports.

> +
>  return 0;
>  }
>  
> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
> index 26ac1fa..ac9f4c8 100644
> --- a/src/qemu/qemu_capabilities.h
> +++ b/src/qemu/qemu_capabilities.h
> @@ -379,6 +379,9 @@ typedef enum {
>  /* 235 */
>  QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE, /* virtio-net-*.rx_queue_size */
>  
> +/* 236 */
> +QEMU_CAPS_GLUSTER_DEBUG_LEVEL, /* -drive debug={0..9} */

You are breaking the pattern.

> +
>  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 545e25d..ad0f1b2 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -1314,7 +1314,8 @@ qemuDiskBusNeedsDeviceArg(int bus)
>  
>  static int
>  qemuBuildDriveSourceStr(virDomainDiskDefPtr disk,
> -virBufferPtr buf)
> +virBufferPtr buf,
> +  virQEMUCapsPtr qemuCaps)

Misaligned.

>  {
>  int actualType = virStorageSourceGetActualType(disk->src);
>  qemuDomainDiskPrivatePtr diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk);
> @@ -1385,7 +1386,8 @@ qemuBuildDriveSourceStr(virDomainDiskDefPtr disk,
>  
>  if (disk->src &&
>  disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
> -virBufferAsprintf(buf, "file.debug=%d,", disk->src->debug_level);
> +if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL))
> +virBufferAsprintf(buf, "file.debug=%d,", disk->src->debug_level);
>  }
>  
>  if (secinfo && secinfo->type == VIR_DOMAIN_SECRET_INFO_TYPE_AES) {
> @@ -1513,7 +1515,7 @@ qemuBuildDriveStr(virDomainDiskDefPtr disk,
>  break;
>  }
>  
> -if (qemuBuildDriveSourceStr(disk, ) < 0)
> +if (qemuBuildDriveSourceStr(disk, , qemuCaps) < 0)
>  goto error;
>  
>  if (emitDeviceSyntax)
> @@ -2263,8 +2265,9 @@ qemuBuildDiskDriveCommandLine(virCommandPtr cmd,
>  
>  if (disk->src &&
>  disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
> -if (cfg->glusterDebugLevel)
> -disk->src->debug_level = cfg->glusterDebugLevel;
> +if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL) &&
> +cfg->glusterDebugLevel)
> +disk->src->debug_level = cfg->glusterDebugLevel;
>  }
>  
>  if (!(optstr = qemuBuildDriveStr(disk, driveBoot, qemuCaps)))
> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
> index dbb0e4d..b29a63b 100644
> --- a/tests/qemuxml2argvtest.c
> +++ b/tests/qemuxml2argvtest.c
> @@ -832,7 +832,8 @@ mymain(void)
>  DO_TEST("disk-drive-network-iscsi-lun",
>  QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_VIRTIO_SCSI,
>  QEMU_CAPS_SCSI_BLOCK);
> -DO_TEST("disk-drive-network-gluster", NONE);
> +DO_TEST("disk-drive-network-gluster",
> +QEMU_CAPS_GLUSTER_DEBUG_LEVEL);

This patch fails make check. You forgot to bundle in some changes.

Peter

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

[libvirt] [PATCH v3 1/2] qemu/gluster: add option for tuning debug logging level

[Prasanna Kumar Kalever]

This helps in selecting log level of the gluster gfapi, output to stderr.
The option is 'gluster_debug_level', can be tuned by editing
'/etc/libvirt/qemu.conf'

Debug levels ranges 0-9, with 9 being the most verbose, and 0 representing
no debugging output.  The default is the same as it was before, which
is a level of 4.  The current logging levels defined in the gluster
gfapi are:

0 - None
1 - Emergency
2 - Alert
3 - Critical
4 - Error
5 - Warning
6 - Notice
7 - Info
8 - Debug
9 - Trace

Signed-off-by: Prasanna Kumar Kalever 
---
 src/qemu/libvirtd_qemu.aug   |  3 +++
 src/qemu/qemu.conf   | 20 
 src/qemu/qemu_command.c  | 14 +-
 src/qemu/qemu_conf.c |  3 +++
 src/qemu/qemu_conf.h |  1 +
 src/util/virstoragefile.h|  2 ++
 .../qemuargv2xml-disk-drive-network-gluster.args |  7 ---
 .../qemuxml2argv-disk-drive-network-gluster.args | 12 ++--
 8 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index 988201e..bdeaeef 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -104,6 +104,8 @@ module Libvirtd_qemu =
 
let nvram_entry = str_array_entry "nvram"
 
+   let debug = int_entry "gluster_debug_level"
+
(* Each entry in the config is one of the following ... *)
let entry = default_tls_entry
  | vnc_entry
@@ -119,6 +121,7 @@ module Libvirtd_qemu =
  | network_entry
  | log_entry
  | nvram_entry
+ | debug
 
let comment = [ label "#comment" . del /#[ \t]*/ "# " .  store /([^ 
\t\n][^\n]*)?/ . del /\n/ "\n" ]
let empty = [ label "#empty" . eol ]
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index e4c2aae..156185a 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -621,3 +621,23 @@
 #  rollover when a size limit is hit.
 #
 #stdio_handler = "logd"
+
+# Qemu gluster libgfapi log level, debug levels are 0-9, with 9 being the
+# most verbose, and 0 representing no debugging output.
+#
+# The current logging levels defined in the gluster GFAPI are:
+#
+#0 - None
+#1 - Emergency
+#2 - Alert
+#3 - Critical
+#4 - Error
+#5 - Warning
+#6 - Notice
+#7 - Info
+#8 - Debug
+#9 - Trace
+#
+# Defaults to 4
+#
+# gluster_debug_level = 9
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 3a61863..545e25d 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -1383,6 +1383,11 @@ qemuBuildDriveSourceStr(virDomainDiskDefPtr disk,
 }
 virBufferAddLit(buf, ",");
 
+if (disk->src &&
+disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
+virBufferAsprintf(buf, "file.debug=%d,", disk->src->debug_level);
+}
+
 if (secinfo && secinfo->type == VIR_DOMAIN_SECRET_INFO_TYPE_AES) {
 /* NB: If libvirt starts using the more modern option based
  * syntax to build the command line (e.g., "-drive driver=rbd,
@@ -2177,6 +2182,7 @@ qemuBuildDriveDevStr(const virDomainDef *def,
 
 static int
 qemuBuildDiskDriveCommandLine(virCommandPtr cmd,
+  virQEMUDriverConfigPtr cfg,
   const virDomainDef *def,
   virQEMUCapsPtr qemuCaps)
 {
@@ -2255,6 +2261,12 @@ qemuBuildDiskDriveCommandLine(virCommandPtr cmd,
 
 virCommandAddArg(cmd, "-drive");
 
+if (disk->src &&
+disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
+if (cfg->glusterDebugLevel)
+disk->src->debug_level = cfg->glusterDebugLevel;
+}
+
 if (!(optstr = qemuBuildDriveStr(disk, driveBoot, qemuCaps)))
 return -1;
 virCommandAddArg(cmd, optstr);
@@ -9613,7 +9625,7 @@ qemuBuildCommandLine(virQEMUDriverPtr driver,
 if (qemuBuildHubCommandLine(cmd, def, qemuCaps) < 0)
 goto error;
 
-if (qemuBuildDiskDriveCommandLine(cmd, def, qemuCaps) < 0)
+if (qemuBuildDiskDriveCommandLine(cmd, cfg, def, qemuCaps) < 0)
 goto error;
 
 if (qemuBuildFSDevCommandLine(cmd, def, qemuCaps) < 0)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index dad8334..8ee99ba 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -311,6 +311,7 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
privileged)
 cfg->seccompSandbox = -1;
 
 cfg->logTimestamp = true;
+cfg->glusterDebugLevel = 4;
 cfg->stdioLogD = true;
 
 #ifdef DEFAULT_LOADER_NVRAM
@@ -780,6 +781,8 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg,
 goto cleanup;
 }
 }
+if (virConfGetValueUInt(conf, "gluster_debug_level", 
>glusterDebugLevel) < 0)
+goto cleanup;

[libvirt] [PATCH v3 2/2] qemu_capabilities: Introduce gluster specific debug capability

[Prasanna Kumar Kalever]

Teach qemu driver to detect whether qemu supports this configuration
factor or not.

Signed-off-by: Prasanna Kumar Kalever 
---
 src/qemu/qemu_capabilities.c |  6 ++
 src/qemu/qemu_capabilities.h |  3 +++
 src/qemu/qemu_command.c  | 13 -
 tests/qemuxml2argvtest.c |  3 ++-
 4 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index c71b4dc..c4350d5 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -344,6 +344,8 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "query-hotpluggable-cpus",
 
   "virtio-net.rx_queue_size", /* 235 */
+
+  "debug",  /* 236 */
 );
 
 
@@ -2496,6 +2498,10 @@ virQEMUCapsProbeQMPCommands(virQEMUCapsPtr qemuCaps,
 qemuMonitorSupportsActiveCommit(mon))
 virQEMUCapsSet(qemuCaps, QEMU_CAPS_ACTIVE_COMMIT);
 
+/* Since qemu 2.7.0 */
+if (qemuCaps->version >= 2007000)
+virQEMUCapsSet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL);
+
 return 0;
 }
 
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 26ac1fa..ac9f4c8 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -379,6 +379,9 @@ typedef enum {
 /* 235 */
 QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE, /* virtio-net-*.rx_queue_size */
 
+/* 236 */
+QEMU_CAPS_GLUSTER_DEBUG_LEVEL, /* -drive debug={0..9} */
+
 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 545e25d..ad0f1b2 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -1314,7 +1314,8 @@ qemuDiskBusNeedsDeviceArg(int bus)
 
 static int
 qemuBuildDriveSourceStr(virDomainDiskDefPtr disk,
-virBufferPtr buf)
+virBufferPtr buf,
+  virQEMUCapsPtr qemuCaps)
 {
 int actualType = virStorageSourceGetActualType(disk->src);
 qemuDomainDiskPrivatePtr diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk);
@@ -1385,7 +1386,8 @@ qemuBuildDriveSourceStr(virDomainDiskDefPtr disk,
 
 if (disk->src &&
 disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
-virBufferAsprintf(buf, "file.debug=%d,", disk->src->debug_level);
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL))
+virBufferAsprintf(buf, "file.debug=%d,", disk->src->debug_level);
 }
 
 if (secinfo && secinfo->type == VIR_DOMAIN_SECRET_INFO_TYPE_AES) {
@@ -1513,7 +1515,7 @@ qemuBuildDriveStr(virDomainDiskDefPtr disk,
 break;
 }
 
-if (qemuBuildDriveSourceStr(disk, ) < 0)
+if (qemuBuildDriveSourceStr(disk, , qemuCaps) < 0)
 goto error;
 
 if (emitDeviceSyntax)
@@ -2263,8 +2265,9 @@ qemuBuildDiskDriveCommandLine(virCommandPtr cmd,
 
 if (disk->src &&
 disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_GLUSTER) {
-if (cfg->glusterDebugLevel)
-disk->src->debug_level = cfg->glusterDebugLevel;
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_GLUSTER_DEBUG_LEVEL) &&
+cfg->glusterDebugLevel)
+disk->src->debug_level = cfg->glusterDebugLevel;
 }
 
 if (!(optstr = qemuBuildDriveStr(disk, driveBoot, qemuCaps)))
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index dbb0e4d..b29a63b 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -832,7 +832,8 @@ mymain(void)
 DO_TEST("disk-drive-network-iscsi-lun",
 QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_VIRTIO_SCSI,
 QEMU_CAPS_SCSI_BLOCK);
-DO_TEST("disk-drive-network-gluster", NONE);
+DO_TEST("disk-drive-network-gluster",
+QEMU_CAPS_GLUSTER_DEBUG_LEVEL);
 DO_TEST("disk-drive-network-rbd", NONE);
 DO_TEST("disk-drive-network-sheepdog", NONE);
 DO_TEST("disk-drive-network-rbd-auth", NONE);
-- 
2.7.4

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

[libvirt] [PATCH v3 0/2] qemu/gluster: add option for tuning debug logging level

[Prasanna Kumar Kalever]

v3:
Add patch 2/2 which address capability checks
Changed 'glusterfs_debug_level' to 'gluster_debug_level' agreeing to Peter
Made changes in libvirtd_qemu.aug
Thanks to Peter & Daniel

v2:
Modify test cases and syntax check changes as suggested by Peter in v1.
Rename qemu_gfapi_debuglevel to glusterfs_debug_level as per Daniel comments.
Fix to make debug_level changes effects on URI along with JSON.

TODO:
* changes in libvirtd_qemu.aug
Which I don't understand for now
* comment on debug_level variable in storage source
Not sure what is the right place
* Capablities check

v1:
Initial post

Prasanna Kumar Kalever (2):
  qemu/gluster: add option for tuning debug logging level
  qemu_capabilities: Introduce gluster specific debug capability

 src/qemu/libvirtd_qemu.aug  |  3 +++
 src/qemu/qemu.conf  | 20 
 src/qemu/qemu_capabilities.c|  6 ++
 src/qemu/qemu_capabilities.h|  3 +++
 src/qemu/qemu_command.c | 21 ++---
 src/qemu/qemu_conf.c|  3 +++
 src/qemu/qemu_conf.h|  1 +
 src/util/virstoragefile.h   |  2 ++
 .../qemuargv2xml-disk-drive-network-gluster.args|  7 ---
 .../qemuxml2argv-disk-drive-network-gluster.args| 12 ++--
 tests/qemuxml2argvtest.c|  3 ++-
 11 files changed, 68 insertions(+), 13 deletions(-)

-- 
2.7.4

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

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Daniel P. Berrange]

On Tue, Sep 20, 2016 at 02:05:52AM +0530, Kirti Wankhede wrote:
> 
> Hi libvirt experts,
> 
> Thanks for valuable input on v1 version of RFC.
> 
> Quick brief, VFIO based mediated device framework provides a way to
> virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT
> and IBM's channel IO. This framework reuses VFIO APIs for all the
> functionalities for mediated devices which are currently being used for
> pass through devices. This framework introduces a set of new sysfs files
> for device creation and its life cycle management.
> 
> Here is the summary of discussion on v1:
> 1. Discover mediated device:
> As part of physical device initialization process, vendor driver will
> register their physical devices, which will be used to create virtual
> device (mediated device, aka mdev) to the mediated framework.
> 
> Vendor driver should specify mdev_supported_types in directory format.
> This format is class based, for example, display class directory format
> should be as below. We need to define such set for each class of devices
> which would be supported by mediated device framework.
> 
>  --- mdev_destroy
>  --- mdev_supported_types
>  |-- 11
>  |   |-- create
>  |   |-- name
>  |   |-- fb_length
>  |   |-- resolution
>  |   |-- heads
>  |   |-- max_instances
>  |   |-- params
>  |   |-- requires_group
>  |-- 12
>  |   |-- create
>  |   |-- name
>  |   |-- fb_length
>  |   |-- resolution
>  |   |-- heads
>  |   |-- max_instances
>  |   |-- params
>  |   |-- requires_group
>  |-- 13
>  |-- create
>  |-- name
>  |-- fb_length
>  |-- resolution
>  |-- heads
>  |-- max_instances
>  |-- params
>  |-- requires_group
> 
> 
> In the above example directory '11' represents a type id of mdev device.
> 'name', 'fb_length', 'resolution', 'heads', 'max_instance' and
> 'requires_group' would be Read-Only files that vendor would provide to
> describe about that type.
> 
> 'create':
> Write-only file. Mandatory.
> Accepts string to create mediated device.
> 
> 'name':
> Read-Only file. Mandatory.
> Returns string, the name of that type id.

Presumably this is a human-targetted title/description of
the device.

> 
> 'fb_length':
> Read-only file. Mandatory.
> Returns {K,M,G}, size of framebuffer.
> 
> 'resolution':
> Read-Only file. Mandatory.
> Returns 'hres x vres' format. Maximum supported resolution.
> 
> 'heads':
> Read-Only file. Mandatory.
> Returns integer. Number of maximum heads supported.

None of these should be mandatory as that makes the mdev
useless for non-GPU devices.

I'd expect to see a 'class' or 'type' attribute in the
directory whcih tells you what kind of mdev it is. A
valid 'class' value would be 'gpu'. The fb_length,
resolution, and heads parameters would only be mandatory
when class==gpu.

> 'max_instance':
> Read-Only file. Mandatory.
> Returns integer.  Returns maximum mdev device could be created
> at the moment when this file is read. This count would be updated by
> vendor driver. Before creating mdev device of this type, check if
> max_instance is > 0.
> 
> 'params'
> Write-Only file. Optional.
> String input. Libvirt would pass the string given in XML file to
> this file and then create mdev device. Set empty string to clear params.
> For example, set parameter 'frame_rate_limiter=0' to disable frame rate
> limiter for performance benchmarking, then create device of type 11. The
> device created would have that parameter set by vendor driver.

Nope, libvirt will explicitly *NEVER* allow arbitrary opaque
passthrough of vendor specific data in this way.

> The parent device would look like:
> 
>
>  pci__86_00_0
>  
>0
>134
>0
>0
>
>  
>  
>
>GRID M60-0B
>512M
>2560x1600
>2
>16
>1
>  

There would need to be a  element, eg gpu

We would then have further elements based on the class. eg

  

GRID M60-0B
512M
2560x1600
2
16
1
  



>
>GRID M60
>NVIDIA
>  
>
> 
> 2. Create/destroy mediated device
> 
> With above example, vGPU device XML would look like:
> 
>
>  my-vgpu
>  pci__86_00_0
>  
>
>1
>'frame_rate_limiter=0'

No, we will not support  in this manner in libvirt.

The entire purpose of libvirt is to represent data in a
vendor agnostic manner and not do abitrary passthrough
of vendor specific data. Simply saying this field is
optional does not get around that either.

>  
>
> 
> 'type id' is mandatory.
> 'group' is optional. It should be a unique number in the system among
> all the groups created for mdev devices. Its usage is:
>   

Re: [libvirt] [PATCH] test: update capability replies for qemu-2.7.0

[Pavel Hrdina]

On Tue, Sep 20, 2016 at 10:47:18AM +0200, Andrea Bolognani wrote:
> On Tue, 2016-09-20 at 10:44 +0200, Pavel Hrdina wrote:
> > Signed-off-by: Pavel Hrdina 
> > ---
> >  .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 39 
> > --
> >  1 file changed, 29 insertions(+), 10 deletions(-)
> > 

[...]

> ACK

Thanks,

Consider this squashed in:

diff --git a/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml 
b/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml
index 7a54040..98f3762 100644
--- a/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml
@@ -28,6 +28,8 @@
   
   
   
+  
+  
   
   
   
@@ -162,6 +164,7 @@
   
   
   
+  
   
   
   
@@ -194,9 +197,9 @@
   
   
   
-  2006091
+  2007000
   0
-   (v2.7.0-rc1-52-g42e0d60)
+   (v2.7.0)
   x86_64
   
   

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

Re: [libvirt] [PATCHv5 00/13] qemu: allow disabling certain virtio revisions

[Cornelia Huck]

On Mon, 19 Sep 2016 22:07:13 +0300
"Michael S. Tsirkin"  wrote:

> On Wed, Sep 07, 2016 at 09:38:04PM +0200, Sascha Silbe wrote:
> > Dear Laine,
> > 
> > Laine Stump  writes:
> > 
> > > On 09/07/2016 02:35 PM, Sascha Silbe wrote:
> > >> "Daniel P. Berrange"  writes:
> > >> [...]
> > >>>== QEMU virtio
> > >>> == QEMU virtio + disable-legacy
> > >> What would this do for devices using the virtio-ccw transport?
> > >
> > >  From libvirt's point of view, the option "disable-legacy=on" would be 
> > > added to the device's commandline argument.
> > 
> > Which would break s390x guests. virtio-ccw doesn't have any concept of
> > "legacy" or "modern" devices (that's purely a virtio-pci concept),
> 
> Legacy is a generic concept found in virtio 1 spec.
> Modern isn't, virtio 1 only has transitional/non-transitional.
> 
> If you want to stick to the spec you should therefore
> use 
>   legacy/transitional/non-transitional
> at the API level.
> 
> It is true that not all transports have all options.
> ccw does not support non-transitional devices,
> mmio does not support transitional ones.

We basically have:
- legacy devices: pci, ccw
- standard-compliant devices: pci, ccw, mmio
  - of these, pci and ccw have transitional support, which can be
disabled for pci

Per default, I don't think libvirt should offer legacy devices - I see
this as a machine-version backwards-compatibility option which should
be handled via the machine version only.

It makes sense to have a way to force pci devices to either
transitional or non-transitional. For ccw and mmio, this is not
applicable. Therefore, I think libvirt should offer a switch to handle
transitional/non-transitional pci only and not provide any other
virtio-version switches.

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

Re: [libvirt] [PATCH] qemu_process: fix a typo

[Andrea Bolognani]

On Tue, 2016-09-20 at 15:37 +0800, Chen Hanxiao wrote:
> From: Chen Hanxiao 
> 
> s/unitl/until
> 
> Signed-off-by: Chen Hanxiao 
> ---
>  src/qemu/qemu_process.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index cecd321..1f56883 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -1678,7 +1678,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
> virDomainObjPtr vm, int asyncJob,
>  }
>  
>  /* Hold an extra reference because we can't allow 'vm' to be
> - * deleted unitl the monitor gets its own reference. */
> + * deleted until the monitor gets its own reference. */
>  virObjectRef(vm);
>  
>  ignore_value(virTimeMillisNow(>monStart));

ACK and pushed. Thanks! :)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [PATCH] test: update capability replies for qemu-2.7.0

[Andrea Bolognani]

On Tue, 2016-09-20 at 10:44 +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> ---
>  .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 39 
> --
>  1 file changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies 
> b/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies
> index 7986dae..ce8dee9 100644
> --- a/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies
> +++ b/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies
> @@ -2,11 +2,11 @@
>"QMP": {
>  "version": {
>"qemu": {
> -"micro": 91,
> -"minor": 6,
> +"micro": 0,
> +"minor": 7,
>  "major": 2
>},
> -  "package": " (v2.7.0-rc1-52-g42e0d60)"
> +  "package": " (v2.7.0)"
>  },
>  "capabilities": [
>  ]
> @@ -22,11 +22,11 @@
>  {
>"return": {
>  "qemu": {
> -  "micro": 91,
> -  "minor": 6,
> +  "micro": 0,
> +  "minor": 7,
>"major": 2
>  },
> -"package": " (v2.7.0-rc1-52-g42e0d60)"
> +"package": " (v2.7.0)"
>},
>"id": "libvirt-2"
>  }
> @@ -466,7 +466,7 @@
>  
>  {
>"return": {
> -"fd": 14,
> +"fd": 13,
>  "fdset-id": 0
>},
>"id": "libvirt-5"
> @@ -696,6 +696,9 @@
>"name": "container"
>  },
>  {
> +  "name": "qio-channel-rdma"
> +},
> +{
>"name": "host-x86_64-cpu"
>  },
>  {
> @@ -1245,6 +1248,9 @@
>"name": "nvdimm"
>  },
>  {
> +  "name": "virtio-balloon-pci"
> +},
> +{
>"name": "SandyBridge-x86_64-cpu"
>  },
>  {
> @@ -1254,6 +1260,9 @@
>"name": "virtio-balloon-device"
>  },
>  {
> +  "name": "ccid-card-passthru"
> +},
> +{
>"name": "qxl"
>  },
>  {
> @@ -1335,7 +1344,7 @@
>"name": "tls-creds-x509"
>  },
>  {
> -  "name": "virtio-balloon-pci"
> +  "name": "ccid-card-emulated"
>  },
>  {
>"name": "ISA"
> @@ -3176,7 +3185,7 @@
>"type": "bool"
>  },
>  {
> -  "name": "any_layout",
> +  "name": "event_idx",
>"description": "on/off",
>"type": "bool"
>  },
> @@ -3191,6 +3200,11 @@
>"type": "bool"
>  },
>  {
> +  "name": "stats",
> +  "description": "on/off",
> +  "type": "bool"
> +},
> +{
>"name": "multifunction",
>"description": "on/off",
>"type": "bool"
> @@ -3206,7 +3220,7 @@
>"type": "bool"
>  },
>  {
> -  "name": "event_idx",
> +  "name": "virgl",
>"description": "on/off",
>"type": "bool"
>  },
> @@ -3248,6 +3262,11 @@
>"type": "int32"
>  },
>  {
> +  "name": "any_layout",
> +  "description": "on/off",
> +  "type": "bool"
> +},
> +{
>"name": "max_outputs",
>"type": "uint32"
>  },

ACK

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[libvirt] [PATCH] test: update capability replies for qemu-2.7.0

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
---
 .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 39 --
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies 
b/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies
index 7986dae..ce8dee9 100644
--- a/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies
+++ b/tests/qemucapabilitiesdata/caps_2.7.0.x86_64.replies
@@ -2,11 +2,11 @@
   "QMP": {
 "version": {
   "qemu": {
-"micro": 91,
-"minor": 6,
+"micro": 0,
+"minor": 7,
 "major": 2
   },
-  "package": " (v2.7.0-rc1-52-g42e0d60)"
+  "package": " (v2.7.0)"
 },
 "capabilities": [
 ]
@@ -22,11 +22,11 @@
 {
   "return": {
 "qemu": {
-  "micro": 91,
-  "minor": 6,
+  "micro": 0,
+  "minor": 7,
   "major": 2
 },
-"package": " (v2.7.0-rc1-52-g42e0d60)"
+"package": " (v2.7.0)"
   },
   "id": "libvirt-2"
 }
@@ -466,7 +466,7 @@
 
 {
   "return": {
-"fd": 14,
+"fd": 13,
 "fdset-id": 0
   },
   "id": "libvirt-5"
@@ -696,6 +696,9 @@
   "name": "container"
 },
 {
+  "name": "qio-channel-rdma"
+},
+{
   "name": "host-x86_64-cpu"
 },
 {
@@ -1245,6 +1248,9 @@
   "name": "nvdimm"
 },
 {
+  "name": "virtio-balloon-pci"
+},
+{
   "name": "SandyBridge-x86_64-cpu"
 },
 {
@@ -1254,6 +1260,9 @@
   "name": "virtio-balloon-device"
 },
 {
+  "name": "ccid-card-passthru"
+},
+{
   "name": "qxl"
 },
 {
@@ -1335,7 +1344,7 @@
   "name": "tls-creds-x509"
 },
 {
-  "name": "virtio-balloon-pci"
+  "name": "ccid-card-emulated"
 },
 {
   "name": "ISA"
@@ -3176,7 +3185,7 @@
   "type": "bool"
 },
 {
-  "name": "any_layout",
+  "name": "event_idx",
   "description": "on/off",
   "type": "bool"
 },
@@ -3191,6 +3200,11 @@
   "type": "bool"
 },
 {
+  "name": "stats",
+  "description": "on/off",
+  "type": "bool"
+},
+{
   "name": "multifunction",
   "description": "on/off",
   "type": "bool"
@@ -3206,7 +3220,7 @@
   "type": "bool"
 },
 {
-  "name": "event_idx",
+  "name": "virgl",
   "description": "on/off",
   "type": "bool"
 },
@@ -3248,6 +3262,11 @@
   "type": "int32"
 },
 {
+  "name": "any_layout",
+  "description": "on/off",
+  "type": "bool"
+},
+{
   "name": "max_outputs",
   "type": "uint32"
 },
-- 
2.10.0

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

[libvirt] [PATCH V2 3/4] qemu: Add domain support for VCPU halted state

[Viktor Mihajlovski]

Adding a field to the domain's private vcpu object to hold the halted
state information.
Adding two functions in support of the halted state:
- qemuDomainGetVcpuHalted: retrieve the halted state from a
  private vcpu object
- qemuDomainRefreshVcpuHalted: obtain the per-vcpu halted states
  via qemu monitor and store the results in the private vcpu objects

Signed-off-by: Viktor Mihajlovski 
Reviewed-by: Bjoern Walk 
Reviewed-by: Hao QingFeng 
Signed-off-by: Boris Fiuczynski 
---
 src/qemu/qemu_domain.c | 69 ++
 src/qemu/qemu_domain.h |  5 
 2 files changed, 74 insertions(+)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 3f16dbe..3fb9b4f 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5956,6 +5956,75 @@ qemuDomainRefreshVcpuInfo(virQEMUDriverPtr driver,
 return ret;
 }
 
+/**
+ * qemuDomainGetVcpuHalted:
+ * @vm: domain object
+ * @vcpu: cpu id
+ *
+ * Returns the vCPU halted state.
+  */
+bool
+qemuDomainGetVcpuHalted(virDomainObjPtr vm,
+unsigned int vcpuid)
+{
+virDomainVcpuDefPtr vcpu = virDomainDefGetVcpu(vm->def, vcpuid);
+return QEMU_DOMAIN_VCPU_PRIVATE(vcpu)->halted;
+}
+
+/**
+ * qemuDomainRefreshVcpuHalted:
+ * @driver: qemu driver data
+ * @vm: domain object
+ * @asyncJob: current asynchronous job type
+ *
+ * Updates vCPU halted state in the private data of @vm.
+ *
+ * Returns number of detected vCPUs on success, -1 on error and reports
+ * an appropriate error, -2 if the domain doesn't exist any more.
+ */
+int
+qemuDomainRefreshVcpuHalted(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+int asyncJob)
+{
+virDomainVcpuDefPtr vcpu;
+qemuMonitorCPUInfoPtr info = NULL;
+size_t maxvcpus = virDomainDefGetVcpusMax(vm->def);
+size_t i;
+bool hotplug;
+int rc;
+int ret = -1;
+
+/* Not supported currently for TCG, see qemuDomainRefreshVcpuInfo */
+if (vm->def->virtType == VIR_DOMAIN_VIRT_QEMU)
+return 0;
+
+hotplug = qemuDomainSupportsNewVcpuHotplug(vm);
+
+if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
+return -1;
+
+rc = qemuMonitorGetCPUInfo(qemuDomainGetMonitor(vm), , maxvcpus, 
hotplug);
+
+if (qemuDomainObjExitMonitor(driver, vm) < 0) {
+ret = -2;
+goto cleanup;
+}
+
+if (rc < 0)
+goto cleanup;
+
+for (i = 0; i < maxvcpus; i++) {
+vcpu = virDomainDefGetVcpu(vm->def, i);
+QEMU_DOMAIN_VCPU_PRIVATE(vcpu)->halted = info[i].halted;
+}
+
+ret = 0;
+
+ cleanup:
+qemuMonitorCPUInfoFree(info, maxvcpus);
+return ret;
+}
 
 bool
 qemuDomainSupportsNicdev(virDomainDefPtr def,
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index a1404d0..03e58c5 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -317,6 +317,7 @@ struct _qemuDomainVcpuPrivate {
 pid_t tid; /* vcpu thread id */
 int enable_id; /* order in which the vcpus were enabled in qemu */
 char *alias;
+bool halted; /* vcpu halted state */
 
 /* information for hotpluggable cpus */
 char *type;
@@ -662,6 +663,10 @@ int qemuDomainRefreshVcpuInfo(virQEMUDriverPtr driver,
   virDomainObjPtr vm,
   int asyncJob,
   bool state);
+bool qemuDomainGetVcpuHalted(virDomainObjPtr vm, unsigned int vcpu);
+int qemuDomainRefreshVcpuHalted(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+int asyncJob);
 
 bool qemuDomainSupportsNicdev(virDomainDefPtr def,
   virDomainNetDefPtr net);
-- 
1.9.1

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

[libvirt] [PATCH V2 2/4] qemu: Add monitor support for CPU halted state

[Viktor Mihajlovski]

Extended the qemuMonitorCPUInfo with a halted flag. Extract the halted
flag for both text and JSON monitor.

Signed-off-by: Viktor Mihajlovski 
Signed-off-by: Boris Fiuczynski 
---
 src/qemu/qemu_monitor.c  | 6 +-
 src/qemu/qemu_monitor.h  | 5 +
 src/qemu/qemu_monitor_json.c | 3 +++
 src/qemu/qemu_monitor_text.c | 8 +++-
 tests/qemumonitorjsontest.c  | 8 
 5 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index b9e2910..c61fac7 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -1677,6 +1677,7 @@ qemuMonitorCPUInfoClear(qemuMonitorCPUInfoPtr cpus,
 cpus[i].thread_id = -1;
 cpus[i].vcpus = 0;
 cpus[i].tid = 0;
+cpus[i].halted = true;
 
 VIR_FREE(cpus[i].qom_path);
 VIR_FREE(cpus[i].alias);
@@ -1725,8 +1726,10 @@ qemuMonitorGetCPUInfoLegacy(struct 
qemuMonitorQueryCpusEntry *cpuentries,
 size_t i;
 
 for (i = 0; i < maxvcpus; i++) {
-if (i < ncpuentries)
+if (i < ncpuentries) {
 vcpus[i].tid = cpuentries[i].tid;
+vcpus[i].halted = cpuentries[i].halted;
+}
 
 /* for legacy hotplug to work we need to fake the vcpu count added by
  * enabling a given vcpu */
@@ -1864,6 +1867,7 @@ qemuMonitorGetCPUInfoHotplug(struct 
qemuMonitorQueryHotpluggableCpusEntry *hotpl
 }
 
 vcpus[anyvcpu].tid = cpuentries[j].tid;
+vcpus[anyvcpu].halted = cpuentries[j].halted;
 }
 
 return 0;
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 615ab3e..8d0aa01 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -394,6 +394,8 @@ int qemuMonitorSystemPowerdown(qemuMonitorPtr mon);
 struct qemuMonitorQueryCpusEntry {
 pid_t tid;
 char *qom_path;
+/* halted indicator */
+bool halted;
 };
 void qemuMonitorQueryCpusFree(struct qemuMonitorQueryCpusEntry *entries,
   size_t nentries);
@@ -441,6 +443,9 @@ struct _qemuMonitorCPUInfo {
 
 /* internal for use in the matching code */
 char *qom_path;
+
+/* halted indicator */
+bool halted;
 };
 typedef struct _qemuMonitorCPUInfo qemuMonitorCPUInfo;
 typedef qemuMonitorCPUInfo *qemuMonitorCPUInfoPtr;
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index de746f1..64f9d01 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -1349,6 +1349,7 @@ qemuMonitorJSONExtractCPUInfo(virJSONValuePtr data,
 for (i = 0; i < ncpus; i++) {
 virJSONValuePtr entry = virJSONValueArrayGet(data, i);
 int thread = 0;
+bool halted = true;
 const char *qom_path;
 if (!entry) {
 ret = -2;
@@ -1358,9 +1359,11 @@ qemuMonitorJSONExtractCPUInfo(virJSONValuePtr data,
 /* Some older qemu versions don't report the thread_id so treat this as
  * non-fatal, simply returning no data */
 ignore_value(virJSONValueObjectGetNumberInt(entry, "thread_id", 
));
+ignore_value(virJSONValueObjectGetBoolean(entry, "halted", ));
 qom_path = virJSONValueObjectGetString(entry, "qom_path");
 
 cpus[i].tid = thread;
+cpus[i].halted = halted;
 if (VIR_STRDUP(cpus[i].qom_path, qom_path) < 0)
 goto cleanup;
 }
diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c
index ff7cc79..f975347 100644
--- a/src/qemu/qemu_monitor_text.c
+++ b/src/qemu/qemu_monitor_text.c
@@ -521,7 +521,7 @@ qemuMonitorTextQueryCPUs(qemuMonitorPtr mon,
  * (qemu) info cpus
  * * CPU #0: pc=0x000f0c4a thread_id=30019
  *   CPU #1: pc=0xfff0 thread_id=30020
- *   CPU #2: pc=0xfff0 thread_id=30021
+ *   CPU #2: pc=0xfff0 (halted) thread_id=30021
  *
  */
 line = qemucpus;
@@ -541,6 +541,12 @@ qemuMonitorTextQueryCPUs(qemuMonitorPtr mon,
 
 cpu.tid = tid;
 
+/* Extract halted indicator */
+if ((offset = strstr(line, "(halted)")) != NULL)
+cpu.halted = true;
+else
+cpu.halted = false;
+
 if (VIR_APPEND_ELEMENT_COPY(cpus, ncpus, cpu) < 0) {
 ret = -1;
 goto cleanup;
diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c
index 9e195d7..8749ea1 100644
--- a/tests/qemumonitorjsontest.c
+++ b/tests/qemumonitorjsontest.c
@@ -1221,10 +1221,10 @@ testQemuMonitorJSONqemuMonitorJSONQueryCPUs(const void 
*data)
 int ret = -1;
 struct qemuMonitorQueryCpusEntry *cpudata = NULL;
 struct qemuMonitorQueryCpusEntry expect[] = {
-{17622, (char *) "/machine/unattached/device[0]"},
-{17624, (char *) "/machine/unattached/device[1]"},
-{17626, (char *) "/machine/unattached/device[2]"},
-{17628, NULL},
+{17622, (char *) "/machine/unattached/device[0]", true},
+

[libvirt] [PATCH V2 4/4] qemu: Ensure reported VCPU state is current in driver API

[Viktor Mihajlovski]

Refresh the VCPU halted states in API functions returning domain
VCPU state information to make sure it's current. This affects
qemuDomainGetVcpus and  qemuDomainGetStatsVcpu

Signed-off-by: Viktor Mihajlovski 
Reviewed-by: Bjoern Walk 
Reviewed-by: Hao QingFeng 
Signed-off-by: Boris Fiuczynski 
---
 src/qemu/qemu_driver.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index e29180d..7105d26 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1478,13 +1478,17 @@ qemuDomainHelperGetVcpus(virDomainObjPtr vm,
 virDomainVcpuDefPtr vcpu = virDomainDefGetVcpu(vm->def, i);
 pid_t vcpupid = qemuDomainGetVcpuPid(vm, i);
 virVcpuInfoPtr vcpuinfo = info + ncpuinfo;
+bool vcpuhalted = qemuDomainGetVcpuHalted(vm, i);
 
 if (!vcpu->online)
 continue;
 
 if (info) {
 vcpuinfo->number = i;
-vcpuinfo->state = VIR_VCPU_RUNNING;
+if (vcpuhalted)
+vcpuinfo->state = VIR_VCPU_HALTED;
+else
+vcpuinfo->state = VIR_VCPU_RUNNING;
 
 if (qemuGetProcessInfo(>cpuTime,
>cpu, NULL,
@@ -5370,6 +5374,7 @@ qemuDomainGetVcpus(virDomainPtr dom,
unsigned char *cpumaps,
int maplen)
 {
+virQEMUDriverPtr driver = dom->conn->privateData;
 virDomainObjPtr vm;
 int ret = -1;
 
@@ -5385,6 +5390,13 @@ qemuDomainGetVcpus(virDomainPtr dom,
 goto cleanup;
 }
 
+if (qemuDomainRefreshVcpuHalted(driver, vm, QEMU_ASYNC_JOB_NONE) < 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   "%s",
+   _("could not refresh CPU states"));
+goto cleanup;
+}
+
 ret = qemuDomainHelperGetVcpus(vm, info, NULL, maxinfo, cpumaps, maplen);
 
  cleanup:
@@ -18863,7 +18875,7 @@ qemuDomainGetStatsBalloon(virQEMUDriverPtr driver,
 
 
 static int
-qemuDomainGetStatsVcpu(virQEMUDriverPtr driver ATTRIBUTE_UNUSED,
+qemuDomainGetStatsVcpu(virQEMUDriverPtr driver,
virDomainObjPtr dom,
virDomainStatsRecordPtr record,
int *maxparams,
@@ -18893,6 +18905,13 @@ qemuDomainGetStatsVcpu(virQEMUDriverPtr driver 
ATTRIBUTE_UNUSED,
 VIR_ALLOC_N(cpuwait, virDomainDefGetVcpus(dom->def)) < 0)
 goto cleanup;
 
+if (qemuDomainRefreshVcpuHalted(driver, dom, QEMU_ASYNC_JOB_NONE) < 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   "%s",
+   _("could not refresh CPU states"));
+goto cleanup;
+}
+
 if (qemuDomainHelperGetVcpus(dom, cpuinfo, cpuwait,
  virDomainDefGetVcpus(dom->def),
  NULL, 0) < 0) {
-- 
1.9.1

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

[libvirt] [PATCH V2 0/4]] qemu: report actual vcpu state in virVcpuInfo

[Viktor Mihajlovski]

Currently, the virVcpuInfo returned by virDomainGetVcpus() will always
report a state of VIR_VCPU_RUNNING for each defined domain vcpu even if
the vcpu is currently in the halted state.

As the monitor interface is in fact reporting the accurate state, it is
rather easy to transport this information with the existing API.

This is done by
- adding a new state of VIR_VCPU_HALTED
- extending the monitor to pass back the halted state for the vcpus
- adding a new field to the private domain vcpu object reflecting the
  halted state for the vcpu
- modifying the driver code to report the vcpu state based on the halted
  indicator
- extending virsh vcpuinfo to also display the halted state

The vcpu state is however not recorded in the internal XML format, since
the state can change asynchronously (without notification).

V2 is a rebase on top of Peter Krempa's CPU hotplug modernization.

Viktor Mihajlovski (4):
  domain: Add new VCPU state "halted"
  qemu: Add monitor support for CPU halted state
  qemu: Add domain support for VCPU halted state
  qemu: Ensure reported VCPU state is current in driver API

 include/libvirt/libvirt-domain.h |  1 +
 src/qemu/qemu_domain.c   | 69 
 src/qemu/qemu_domain.h   |  5 +++
 src/qemu/qemu_driver.c   | 23 --
 src/qemu/qemu_monitor.c  |  6 +++-
 src/qemu/qemu_monitor.h  |  5 +++
 src/qemu/qemu_monitor_json.c |  3 ++
 src/qemu/qemu_monitor_text.c |  8 -
 tests/qemumonitorjsontest.c  |  8 ++---
 tools/virsh-domain.c |  3 +-
 10 files changed, 122 insertions(+), 9 deletions(-)

-- 
1.9.1

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