Re: [libvirt PATCH v3 0/8] Support for VFIO variant drivers, Part 1

[Joao Martins]

On 21/08/2023 20:32, Laine Stump wrote:
> A "VFIO variant" driver is a kernel driver for a device that supports
> all the APIs of the basic vfio-pci driver (which enables assigning a
> host PCI device to a QEMU guest) plus "some extra stuff" (e.g. to
> enable things like saving/restoring device state in order to support
> live migration.)
> 
> Way back last year I posted a couple attempts to support VFIO variant
> drivers; here is V2 (along with a later followup discussion from a
> couple months ago):
> 
> https://listman.redhat.com/archives/libvir-list/2022-August/233661.html
> https://listman.redhat.com/archives/libvir-list/2023-May/240108.html
> 
> The mlx5-vfio-pci driver has now been upstream for quite awhile (and
> even in the downstream Fedora 38 kernel, for example), as are the
> sysfs bits that allow us to determine whether or not a driver is a
> VFIO variant, and I've updated the patch(es) to use this.
> 
> I've also been working on auto-binding to the "best-match" VFIO
> variant driver based on comparing the device's modalias file in sysfs
> to the contents of the kernel's modules.alias file, but that isn't
> quite ready (partly code that isn't yet working, but also partly
> indecision about exactly where in the XML to put the driver name when
> it is specified; I won't take up more space here with that though).
> 
Don't we have a:


   ...
   
   ...
 In the meantime, there are people who want to use the mlx5-vfio-pci
> driver (and Cedric Le Goater also has written vfio-pci-igbvf and
> vfio-pci-e1000e drivers (which area very useful for testing), although
> I don't think he has posted them anywhere yet), 

Interesting, e1000e and igbvf have quiesce/resume/dirty-tracking commands?
Sounds too old to have :D unless of course this is Qemu-created commands and not
actual IGB/E1000e hardware doing those

> so I would like to get
> the basic patches here merged in upstream now while I continue working
> on "Part 2".
> 
> These patches provide two improvements that make testing/using VFIO
> drivers much more convenient:
> 
> 1) The specific driver can be given in the virsh nodedev-detach
> command (or the virNodeDeviceDetachFlags() API call), e.g.:
> 
> virsh nodedev-detach pci__04_11_5 --driver vfio-pci-igbvf
> 
> 2) If the  (or " ... " has
> "managed='no'", then libvirt will recognize any VFIO variant driver
> (rather than the current behavior of rejecting anything that isn't
> exactly "vfio-pci")
> 
> With these two capabilities, it's simple and straightforward to bind a
> device to a VFIO variant driver, and then start a guest that uses that
> device.
> 

Nice

Provided the initial use of VFIO variant drivers have been to support live
migration, should the hostdev blocker be lifted too *just in case
it is simple addition of course* ?

In vfio 8.1 it is enabled by default, so there isn't much else to do other than
unblock migration with hostdevs. Something like below is  specific;
which works but it is likely too specific:

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index d21551ab07d9..6edc8583c539 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1316,13 +1316,15 @@ qemuMigrationSrcIsAllowedHostdev(const virDomainDef 
*def)
 continue;
 }

-/* all other PCI hostdevs can't be migrated */
+/* some PCI hostdevs can't be migrated */
 if (hostdev->parentnet) {
-virDomainNetType actualType =
virDomainNetGetActualType(hostdev->parentnet);
-
-virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
-   _("cannot migrate a domain with "),
-   virDomainNetTypeToString(actualType));
+/*
+ * Some VFIO network devices can be migrated if vendor
+ * VFIO driver is used e.g. via mlx5-vfio-pci.
+ * We leave it up to the live migration blocker in Qemu to
+ * stop us from proceeding.
+ */
+continue;
 } else {
 virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("cannot migrate a domain with "),


Or even something like this generic to the hostdev as long as it's assigned to a
variant driver. For any off shot case that isn't a migration vfio driver then
Qemu will fail for us as it will fail to probe the right things e.g. (below is
totally untested, it is just for illustration purposes, we can probably do away
with just VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO and let Qemu block migration for 
us?)

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index d21551ab07d9..1f29493aa0c2 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1301,6 +1301,8 @@ qemuMigrationSrcIsAllowedHostdev(const virDomainDef *def)
 return false;

 

Re: [PATCH v2] util: basic support for VFIO variant drivers

[Joao Martins]

On 31/05/2023 15:31, Jason Gunthorpe wrote:
> On Wed, May 31, 2023 at 03:18:17PM +0100, Joao Martins wrote:
>> Hey Laine,
>>
>> On 23/08/2022 15:11, Laine Stump wrote:
>>> ping.
>>>
>>> I have a different version of this patch where I do read the modules.alias 
>>> file
>>> rather than just checking the name of the driver, but that also requires 
>>> "double
>>> mocking" open() in the unit test, which wasn't working properly, and I'd 
>>> rather
>>> not spend the time figuring it out if it's not going to be needed. (Alex 
>>> prefers
>>> that version because it is more correct than just checking the name, and 
>>> he's
>>> concerned that the new sysfs-based API may take longer than we're thinking 
>>> to
>>> get into downstream distros, but the version in this patch does satisfy both
>>> Jason and Daniel's suggested implementations). Anyway, I can post the other
>>> patch if anyone is interested.
>>>
>> [sorry for the thread necromancy]
>>
>> I was wondering if you're planning on respinning this work, or rather the
>> modalias approach alternative you mention? Or perhaps we are waiting for the
>> cdev sysfs? Though, there's still a significant amount of kernel versions to
>> cover that won't have the sysfs entry sadly :(
> 
> The cdev sysfs has been merged to the kernel now

Ugh, I got confused with something else enterily. Yes, it's there since commit
3c28a76124b258 ("vfio: Add struct device to vfio_device"), v6.1 essentially;

Re: [PATCH v2] util: basic support for VFIO variant drivers

[Joao Martins]

Hey Laine,

On 23/08/2022 15:11, Laine Stump wrote:
> ping.
> 
> I have a different version of this patch where I do read the modules.alias 
> file
> rather than just checking the name of the driver, but that also requires 
> "double
> mocking" open() in the unit test, which wasn't working properly, and I'd 
> rather
> not spend the time figuring it out if it's not going to be needed. (Alex 
> prefers
> that version because it is more correct than just checking the name, and he's
> concerned that the new sysfs-based API may take longer than we're thinking to
> get into downstream distros, but the version in this patch does satisfy both
> Jason and Daniel's suggested implementations). Anyway, I can post the other
> patch if anyone is interested.
> 
[sorry for the thread necromancy]

I was wondering if you're planning on respinning this work, or rather the
modalias approach alternative you mention? Or perhaps we are waiting for the
cdev sysfs? Though, there's still a significant amount of kernel versions to
cover that won't have the sysfs entry sadly :(

> On 8/11/22 1:00 AM, Laine Stump wrote:
>> Before a PCI device can be assigned to a guest with VFIO, that device
>> must be bound to the vfio-pci driver rather than to the device's
>> normal driver. The vfio-pci driver provides APIs that permit QEMU to
>> perform all the necessary operations to make the device accessible to
>> the guest.
>>
>> There has been kernel work recently to support vendor/device-specific
>> VFIO variant drivers that provide the basic vfio-pci driver functionality
>> while adding support for device-specific operations (for example these
>> device-specific drivers are planned to support live migration of
>> certain devices). All that will be needed to make this functionality
>> available will be to bind the new vendor-specific driver to the device
>> (rather than the generic vfio-pci driver, which will continue to work
>> just without the extra functionality).
>>
>> But until now libvirt has required that all PCI devices being assigned
>> to a guest with VFIO specifically have the "vfio-pci" driver bound to
>> the device. So even if the user manually binds a shiny new
>> vendor-specific vfio variant driver to the device (and puts
>> "managed='no'" in the config to prevent libvirt from changing the
>> binding), libvirt will just fail during startup of the guest (or
>> during hotplug) because the driver bound to the device isn't exactly
>> "vfio-pci".
>>
>> This patch loosens that restriction a bit - rather than requiring that
>> the device be bound to "vfio-pci", it also checks if the drivername
>> contains the string "vfio" at all, and in this case allows the
>> operation to continue. If the driver is in fact a VFIO variant, then
>> the assignment will succeed, but if it is not a VFIO variant then QEMU
>> will fail (and report the error back to libvirt).
>>
>> In the near future (possibly by kernel 6.0) there will be a
>> formal method of identifying a VFIO variant driver by looking in
>> sysfs; in the meantime the inexact, but simple, method in this patch
>> will allow users of the few existing VFIO variant drivers (and
>> developers of new VFIO variant drivers) to use their new drivers
>> without needing to remove libvirt from their setup - they can simply
>> pre-bind the device to the new driver, then use "managed='no'" in
>> their libvirt config.
>>
>> NB: this patch does *not* handle automatically determining the proper
>> vendor-specific driver and binding to it in the case of
>> "managed='yes'". This will be implemented later when there is a widely
>> available driver / device combo we can use for testing.
>>
>> Signed-off-by: Laine Stump 
>> ---
>> V1 here: 
>> https://listman.redhat.com/archives/libvir-list/2022-August/233327.html
>>
>> Change in V2:
>>
>> V1 used the output of modinfo to look for "vfio_pci" as an alias for a
>> driver to see if it was a VFIO variant driver.
>>
>> As a result of discussion of V1, V2 is much simpler - it just assumes
>> that any driver with "vfio" in the name is a VFIO variant. This is
>> okay because 1) QEMU will still catch it and libvirt will properly log
>> the error if the driver isn't actually a VFIO variant, and 2) it's a
>> temporary situation, just to enable use of VFIO variant drivers with
>> libvirt until a standard method of detecting this is added to sysfs
>> (which, according to the discussion of V1, is coming in the near
>> future).
>>
>> (NB: I did implement checking of /lib/modules/`uname -r`/modules.alias
>> as suggested by Erik, but it turned out that this caused the unit
>> tests to call uname(3) and open the modules.alias file on the test
>> host - for a proper unit test I would have also needed to mock these
>> two functions, and it seemed like too much complexity for a temporary
>> workaround. I've implemented Jason's suggestion here (accept any
>> driver with "vfio" in the name), which is similar to danpb's
>> suggestion (accept specifically the two drivers that are 

Re: [libvirt] [PATCH v3.1 3/6] libxl: add support for CPUID features policy

[Joao Martins]

On 01/04/2018 12:43 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 03, 2018 at 05:00:10PM -0700, Jim Fehlig wrote:
>> On 12/19/2017 06:19 AM, Joao Martins wrote:
>>> On 12/13/2017 07:09 PM, Marek Marczykowski-Górecki wrote:
>>>> +/*
>>>> + * Translate CPU feature name from libvirt to libxl (from_libxl=false) or 
>>>> from
>>>> + * libxl to libvirt (from_libxl=true).
>>>> + */
>>>> +const char *
>>>> +xenTranslateCPUFeature(const char *feature_name, bool from_libxl)
>>>> +{
>>>> +static const char *translation_table[][2] = {
>>>> +/* libvirt name, libxl name */
>>>> +{ "cx16", "cmpxchg16" },
>>>> +{ "cid", "cntxid" },
>>>> +{ "ds_cpl", "dscpl" },
>>>> +{ "pclmuldq", "pclmulqdq" },
>>>> +{ "pni", "sse3" },
>>>> +{ "ht", "htt" },
>>>> +{ "pn", "psn" },
>>>> +{ "clflush", "clfsh" },
>>>> +{ "sep", "sysenter" },
>>>> +{ "cx8", "cmpxchg8" },
>>>> +{ "nodeid_msr", "nodeid" },
>>>> +{ "cr8legacy", "altmovcr8" },
>>>> +{ "lahf_lm", "lahfsahf" },
>>>> +{ "cmp_legacy", "cmplegacy" },
>>>> +{ "fxsr_opt", "ffxsr" },
>>>> +{ "pdpe1gb", "page1gb" },
>>>> +};
>>>> +size_t i;
>>>> +
>>>> +for (i = 0; i < ARRAY_CARDINALITY(translation_table); i++)
>>>> +if (STREQ(translation_table[i][from_libxl], feature_name))
>>>> +return translation_table[i][!from_libxl];
>>>> +return feature_name;
>>>> +}
>>>> +
>>>
>>> Cc'ing Jim as he may have some thoughts on the direction of this.
>>>
>>> What happens if the admin decides to change /usr/share/libvirt/cpu_map.xml?
>>
>> Is changing existing content likely/practical?
>>
>>> Also you can also add new leafs/features to cpu_map.xml
>>
>> Right. And I suppose the table in libxl_cpuid.c can grow too. And in cases
>> where they differ we'd need to update the static table, which we'll probably
>> only remember to do when receiving bug reports. So I like the idea of making
>> this more dynamic, but I apparently don't have enough brain power today to
>> understand your suggestion :-).
>>
>>> Maybe an idea instead is to have a table with all leafs that libxl has 
>>> hardcoded
>>> (i.e. cpuid_flags array on
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_cpuid.c;hb=HEAD#l92).
>>
>> Where would this table reside? In src/cpu/?
>>
>>> Then adding a new cpu driver routine to look for cpuid data based on feature
>>> name (and the reverse too). Finally you would populate this translation 
>>> table at
>>> driver load time, or you could even get away without a translation table 
>>> (but
>>> would be a little more inefficient?).
>>
>> I'm having difficulty understanding how this provides a dynamic solution.
>> Wouldn't the table you mention above need extended anytime the hardcoded one
>> in libxl was extended? Which would probably only happen after receiving a
>> bug report? :-)
> 
> Probably... And worse thing about such table is it needs to contain all
> entries from said libxl_cpuid.c. My solution require only listing
> entries with mismatching names.
> 
/nods and it would be a gigantic table most likely.

> Alternative would be to not use "new libxl syntax", but "old xend
> syntax" (which is still supported by libxl). The later allow to list
> specific bits instead of feature names. That was implemented in v1 of
> this patch series[1]... The problem with that approach is currently libvirt
> does not expose API for lookup of individual features, but only to
> construct full CPU and then enumerate its CPUID.

I kinda liked your xend version, provided we could lookup the feature bits as
you are hinting here.

> That means it isn't
> feasible for the current approach (mode='host-passthrough', then
> enable/disable individual features). See discussion on v1.
> Adding such API to libvirt cpu driver is beyond my knowledge of libvirt
> code and available time :/
> 
The main reason I suggesting this out was because this patch was hardcoding
libvirt feature names. Maybe it's not an issue :)

Joao

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

Re: [libvirt] [PATCH v3.1 3/6] libxl: add support for CPUID features policy

[Joao Martins]

On 01/04/2018 12:00 AM, Jim Fehlig wrote:
> On 12/19/2017 06:19 AM, Joao Martins wrote:
>> On 12/13/2017 07:09 PM, Marek Marczykowski-Górecki wrote:
>>> Convert CPU features policy into libxl cpuid policy settings. Use new
>>> ("libxl") syntax, which allow to enable/disable specific bits, using
>>> host CPU as a base. For this reason, only "host-passthrough" mode is
>>> accepted.
>>> Libxl do not have distinction between "force" and "required" policy
>>> (there is only "force") and also between "forbid" and "disable" (there
>>> is only "disable"). So, merge them appropriately. If anything, "require"
>>> and "forbid" should be enforced outside of specific driver.
>>>
>>> Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
>>
>> This is quite neat Marek :)
>>
>> I have one comment towards the end, suggesting an alternative to a static
>> translation table.
>>
>>> ---
>>> Changes since v3:
>>>   - compile fix (one more 
>>> s/libxlTranslateCPUFeature/xenTranslateCPUFeature/)
>>> Changes since v2:
>>>   - drop spurious changes
>>>   - move libxlTranslateCPUFeature function to xen_xl.c, to be reused by
>>>   xenconfig driver
>>> Changes since v1:
>>>   - use new ("libxl") syntax to set only bits explicitly mentioned in
>>>   domain XML
>>> ---
>>>   src/libxl/libxl_conf.c | 35 +--
>>>   src/xenconfig/xen_xl.c | 34 ++
>>>   src/xenconfig/xen_xl.h |  2 ++
>>>   3 files changed, 69 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index 184610966..5eae6d10f 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -50,6 +50,7 @@
>>>   #include "secret_util.h"
>>>   #include "cpu/cpu.h"
>>>   #include "xen_common.h"
>>> +#include "xen_xl.h"
>>>   
>>>   
>>>   #define VIR_FROM_THIS VIR_FROM_LIBXL
>>> @@ -357,6 +358,7 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>>>   bool hasHwVirt = false;
>>>   int nested_hvm = -1;
>>>   bool svm = false, vmx = false;
>>> +char xlCPU[32];
>>>   
>>>   if (def->cpu->mode != (VIR_CPU_MODE_HOST_PASSTHROUGH)) {
>>>   virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
>>> @@ -379,15 +381,44 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>>>   case VIR_CPU_FEATURE_DISABLE:
>>>   case VIR_CPU_FEATURE_FORBID:
>>>   if ((vmx && STREQ(def->cpu->features[i].name, 
>>> "vmx")) ||
>>> -(svm && STREQ(def->cpu->features[i].name, 
>>> "svm")))
>>> +(svm && STREQ(def->cpu->features[i].name, 
>>> "svm"))) {
>>>   nested_hvm = 0;
>>> +continue;
>>> +}
>>> +
>>> +snprintf(xlCPU,
>>> +sizeof(xlCPU),
>>> +"%s=0",
>>> +xenTranslateCPUFeature(
>>> +def->cpu->features[i].name,
>>> +false));
>>> +if (libxl_cpuid_parse_config(_info->cpuid, 
>>> xlCPU)) {
>>> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
>>> +_("unsupported cpu feature '%s'"),
>>> +def->cpu->features[i].name);
>>> +return -1;
>>> +}
>>>   break;
>>>   
>>>   case VIR_CPU_FEATURE_FORCE:
>>>   case VIR_CPU_FEATURE_REQUIRE:
>>>   if ((vmx && STREQ(def->cpu->features[i].name, 
>>> "vmx")) ||
>>> -

Re: [libvirt] [PATCH v3 2/6] libxl: do not enable nested HVM by mere presence of element

[Joao Martins]

On 12/19/2017 01:13 PM, Daniel P. Berrange wrote:
> On Tue, Dec 19, 2017 at 01:01:36PM +0000, Joao Martins wrote:
>> [Sorry for double posting, but I mistakenly forgot to include libvirt list)
>>
>> +WimT +Daniel
>>
>> On 12/10/2017 02:10 AM, Marek Marczykowski-Górecki wrote:
>>>  element may be used to configure other
>>> features, like NUMA, or CPUID. Do not enable nested HVM (which is in
>>> "preview" state after all) by mere presence of
>>>  element, but require explicit >> policy='force' name='vmx'/> (or 'svm').
>>> Also, adjust xenconfig driver to appropriately translate to/from
>>> nestedhvm=1.
>>>
>>> While at it, adjust xenconfig driver to not override def->cpu if already
>>> set elsewhere. This will help with adding cpuid support.
>>
>> I agree with this and it was what we came up in the first version of nested 
>> hvm
>> support[0]. Although Daniel suggested there to use the same semantics of qemu
>> driver such that host-passthrough enables nested hvm without the use of:
>>
>> 
> 
> Yes, the key point of libvirt is to apply consistent semantics across 
> different
> drivers, so we should not diverge betweeen QEMU & Xen in this regard.
> 

/nods

> 'host-passthrough' and 'host-model' are supposed to expose *every* feature 
> that
> the host CPUs support (except for those few which the hypervisor may block due
> to ability to virtualize them).
> 
> So 'host-passthrough' is correct to automatically expose vmx/svm, without
> requiring any extra  element, and I don't think we can accept
> this patch.
> 
> This has been the case for KVM for ages, even though it has been considered
> experimental.  The only slight difference is that you can block use of svm/vmx
> at the host OS level via a kernel arg to the kvm modules.
> 
Ah that's where Xen falls off a little in which there's only libxl nested_hvm
field to control it, even though is still marked Experimental. There's no global
parameter to block it.

> If you want to not expose svm/vmx to the guest, despite it being available
> in the host, then use feature policy=disble when configuring it.
> 
>> (I think you propose policy='force' here which is probably better suited as
>> opposed to policy='require')
> 
> It depends on what semantics the Xen hypervisor provides.
> 
> 'require' means expose the feature to the guest if it is supported
> by the host, but raise an error if the host doesn't support it.
> 
> 'force' means expose the feature to the guest, even if the host does
> not support it at all.
> 
> For HVM Xen guests there's no real distinction between these, as you
> can't run an HVM Xen guest without having hardware virt in your
> host.  So for 'vmx'  / 'svm'  force/require are basically the same
> thing. For other CPU feature bits they are definitely different.

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

Re: [libvirt] [PATCH v3.1 3/6] libxl: add support for CPUID features policy

[Joao Martins]

On 12/13/2017 07:09 PM, Marek Marczykowski-Górecki wrote:
> Convert CPU features policy into libxl cpuid policy settings. Use new
> ("libxl") syntax, which allow to enable/disable specific bits, using
> host CPU as a base. For this reason, only "host-passthrough" mode is
> accepted.
> Libxl do not have distinction between "force" and "required" policy
> (there is only "force") and also between "forbid" and "disable" (there
> is only "disable"). So, merge them appropriately. If anything, "require"
> and "forbid" should be enforced outside of specific driver.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

This is quite neat Marek :)

I have one comment towards the end, suggesting an alternative to a static
translation table.

> ---
> Changes since v3:
>  - compile fix (one more s/libxlTranslateCPUFeature/xenTranslateCPUFeature/)
> Changes since v2:
>  - drop spurious changes
>  - move libxlTranslateCPUFeature function to xen_xl.c, to be reused by
>  xenconfig driver
> Changes since v1:
>  - use new ("libxl") syntax to set only bits explicitly mentioned in
>  domain XML
> ---
>  src/libxl/libxl_conf.c | 35 +--
>  src/xenconfig/xen_xl.c | 34 ++
>  src/xenconfig/xen_xl.h |  2 ++
>  3 files changed, 69 insertions(+), 2 deletions(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index 184610966..5eae6d10f 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -50,6 +50,7 @@
>  #include "secret_util.h"
>  #include "cpu/cpu.h"
>  #include "xen_common.h"
> +#include "xen_xl.h"
>  
>  
>  #define VIR_FROM_THIS VIR_FROM_LIBXL
> @@ -357,6 +358,7 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>  bool hasHwVirt = false;
>  int nested_hvm = -1;
>  bool svm = false, vmx = false;
> +char xlCPU[32];
>  
>  if (def->cpu->mode != (VIR_CPU_MODE_HOST_PASSTHROUGH)) {
>  virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> @@ -379,15 +381,44 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>  case VIR_CPU_FEATURE_DISABLE:
>  case VIR_CPU_FEATURE_FORBID:
>  if ((vmx && STREQ(def->cpu->features[i].name, 
> "vmx")) ||
> -(svm && STREQ(def->cpu->features[i].name, 
> "svm")))
> +(svm && STREQ(def->cpu->features[i].name, 
> "svm"))) {
>  nested_hvm = 0;
> +continue;
> +}
> +
> +snprintf(xlCPU,
> +sizeof(xlCPU),
> +"%s=0",
> +xenTranslateCPUFeature(
> +def->cpu->features[i].name,
> +false));
> +if (libxl_cpuid_parse_config(_info->cpuid, 
> xlCPU)) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> +_("unsupported cpu feature '%s'"),
> +def->cpu->features[i].name);
> +return -1;
> +}
>  break;
>  
>  case VIR_CPU_FEATURE_FORCE:
>  case VIR_CPU_FEATURE_REQUIRE:
>  if ((vmx && STREQ(def->cpu->features[i].name, 
> "vmx")) ||
> -(svm && STREQ(def->cpu->features[i].name, 
> "svm")))
> +(svm && STREQ(def->cpu->features[i].name, 
> "svm"))) {
>  nested_hvm = 1;
> +continue;
> +}
> +
> +snprintf(xlCPU,
> +sizeof(xlCPU),
> +"%s=1",
> +xenTranslateCPUFeature(
> +def->cpu->features[i].name, false));
> +if (libxl_cpuid_parse_config(_info->cpuid, 
> xlCPU)) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> +_("unsupported cpu feature '%s'"),
> +def->cpu->features[i].name);
> +return -1;
> +}
>  break;
>  case VIR_CPU_FEATURE_OPTIONAL:
>  case VIR_CPU_FEATURE_LAST:
> diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
> index 317c7a08d..356ca3a4b 100644
> --- a/src/xenconfig/xen_xl.c
> +++ b/src/xenconfig/xen_xl.c
> @@ -225,6 +225,40 @@ xenParseXLOS(virConfPtr conf, virDomainDefPtr def, 
> virCapsPtr caps)
>

Re: [libvirt] [PATCH v3 2/6] libxl: do not enable nested HVM by mere presence of element

[Joao Martins]

[Sorry for double posting, but I mistakenly forgot to include libvirt list)

+WimT +Daniel

On 12/10/2017 02:10 AM, Marek Marczykowski-Górecki wrote:
>  element may be used to configure other
> features, like NUMA, or CPUID. Do not enable nested HVM (which is in
> "preview" state after all) by mere presence of
>  element, but require explicit  policy='force' name='vmx'/> (or 'svm').
> Also, adjust xenconfig driver to appropriately translate to/from
> nestedhvm=1.
> 
> While at it, adjust xenconfig driver to not override def->cpu if already
> set elsewhere. This will help with adding cpuid support.
> I agree with this and it was what we came up in the first version of nested 
> hvm
support[0]. Although Daniel suggested there to use the same semantics of qemu
driver such that host-passthrough enables nested hvm without the use of:



(I think you propose policy='force' here which is probably better suited as
opposed to policy='require')

[0] https://www.redhat.com/archives/libvir-list/2017-March/msg00330.html

Some small comments most of them nitpicks that may fall in individuals style
preference.

> ---
> Changes since v2:
>  - new patch
> ---
>  src/libxl/libxl_conf.c | 10 ++-
>  src/xenconfig/xen_xl.c | 57 +--
>  tests/libxlxml2domconfigdata/vnuma-hvm.json|  1 +-
>  tests/xlconfigdata/test-fullvirt-nestedhvm.xml |  4 +-
>  4 files changed, 40 insertions(+), 32 deletions(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index f39e783..1846109 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -355,6 +355,7 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>  
>  if (caps && def->cpu) {
>  bool hasHwVirt = false;
> +int nested_hvm = -1;

Why not assume nested_hvm set to 0 (replicating libxl behaviour of default
disabled) and then [*]

>  bool svm = false, vmx = false;
>  
>  if (def->cpu->mode != (VIR_CPU_MODE_HOST_PASSTHROUGH)) {
> @@ -379,18 +380,23 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>  case VIR_CPU_FEATURE_FORBID:
>  if ((vmx && STREQ(def->cpu->features[i].name, 
> "vmx")) ||
>  (svm && STREQ(def->cpu->features[i].name, 
> "svm")))
> -hasHwVirt = false;

You remove this, but it might be needed given that right before this chunk we
set hasHwVirt to true depending on whether host cpu supports it.

> +nested_hvm = 0;
>  break;
>  

[*] Just removing the nested_hvm being set to 0 here ...

>  case VIR_CPU_FEATURE_FORCE:
>  case VIR_CPU_FEATURE_REQUIRE:
> +if ((vmx && STREQ(def->cpu->features[i].name, 
> "vmx")) ||
> +(svm && STREQ(def->cpu->features[i].name, 
> "svm")))
> +nested_hvm = 1;> +   
>  break;

... and instead simply have this one here.

>  case VIR_CPU_FEATURE_OPTIONAL:
>  case VIR_CPU_FEATURE_LAST:
>  break;
>  }
>  }
>  }
> -libxl_defbool_set(_info->u.hvm.nested_hvm, hasHwVirt);
> +if (hasHwVirt && nested_hvm != -1)
> +libxl_defbool_set(_info->u.hvm.nested_hvm, nested_hvm);

An alternative would be the as to always set like previously done:

libxl_defbool_set(_info->u.hvm.nested_hvm, hasHwVirt && nestedHvm);

And thus not needing the if that you are preceding here.

>  }
>  
>  if (def->nsounds > 0) {
> diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
> index 9e239a7..317c7a0 100644
> --- a/src/xenconfig/xen_xl.c
> +++ b/src/xenconfig/xen_xl.c
> @@ -170,16 +170,7 @@ xenParseXLOS(virConfPtr conf, virDomainDefPtr def, 
> virCapsPtr caps)
>  if (xenConfigGetBool(conf, "nestedhvm", , -1) < 0)
>  return -1;
>  
> -if (val == 1) {
> -virCPUDefPtr cpu;
> -
> -if (VIR_ALLOC(cpu) < 0)
> -return -1;
> -
> -cpu->mode = VIR_CPU_MODE_HOST_PASSTHROUGH;
> -cpu->type = VIR_CPU_TYPE_GUEST;
> -def->cpu = cpu;
> -} else if (val == 0) {
> +if (val != -1) {
>  const char *vtfeature = NULL;
>  
>  if (caps && caps->host.cpu && ARCH_IS_X86(def->os.arch)) {
> @@ -190,26 +181,29 @@ xenParseXLOS(virConfPtr conf, virDomainDefPtr def, 
> virCapsPtr caps)
>  }
>  
>  if (vtfeature) {
> -virCPUDefPtr cpu;
> -
> -if (VIR_ALLOC(cpu) < 0)
> -return -1;
> +if (!def->cpu) {
> +virCPUDefPtr cpu;
> +if (VIR_ALLOC(cpu) < 0)
> +return -1;
>  
> 

Re: [libvirt] [PATCH v3] libxl: Add a test suite for libxl_domain_config generator

[Joao Martins]

On Tue, Aug 01, 2017 at 03:17:51PM +0200, Marek Marczykowski-Górecki wrote:
> From: Jim Fehlig <jfeh...@suse.com>
> 
> The libxl library allows a libxl_domain_config object to be serialized
> from/to a JSON string. Use this to allow testing of the XML to
> libxl_domain_config conversion process. Test XML is converted to
> libxl_domain_config, which is then serialized to json. A json template
> corresponding to the test XML is converted to a libxl_domain_config
> object using libxl_domain_config_from_json(), and then serialized
> back to json using libxl_domain_config_to_json(). The two json
> docs are then compared.
> 
> Using libxl to convert the json template to a libxl_domain_config
> object and then back to json provides a simple way to account for
> any changes or additions to the json representation across Xen
> releases.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
> [update to v3.5.0-rc1, improve error reporting, use /bin/true emulator]
> Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>

I've been looking at this series for the past days, and taking into
account the comments that Jim mentioned yesterday are ammended, and this
looks good to me:

Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>

It adds a really nice piece of testing infra for libxl_domain_configs.
Maybe in the future more tests could be added in (in addition to the
CPUID one that Marek has planned).

Joao

> ---
>  m4/virt-driver-libxl.m4|   6 +-
>  tests/Makefile.am  |  18 +-
>  tests/libxlxml2domconfigdata/basic-hvm.json|  89 -
>  tests/libxlxml2domconfigdata/basic-hvm.xml |  36 +++-
>  tests/libxlxml2domconfigdata/basic-pv.json |  65 ++-
>  tests/libxlxml2domconfigdata/basic-pv.xml  |  28 ++-
>  tests/libxlxml2domconfigdata/moredevs-hvm.json | 111 ++-
>  tests/libxlxml2domconfigdata/moredevs-hvm.xml  |  63 ++-
>  tests/libxlxml2domconfigtest.c | 205 ++-
>  tests/virmocklibxl.c   |  87 -
>  10 files changed, 705 insertions(+), 3 deletions(-)
>  create mode 100644 tests/libxlxml2domconfigdata/basic-hvm.json
>  create mode 100644 tests/libxlxml2domconfigdata/basic-hvm.xml
>  create mode 100644 tests/libxlxml2domconfigdata/basic-pv.json
>  create mode 100644 tests/libxlxml2domconfigdata/basic-pv.xml
>  create mode 100644 tests/libxlxml2domconfigdata/moredevs-hvm.json
>  create mode 100644 tests/libxlxml2domconfigdata/moredevs-hvm.xml
>  create mode 100644 tests/libxlxml2domconfigtest.c
>  create mode 100644 tests/virmocklibxl.c
> 
> diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
> index 96a9d47..3d635f0 100644
> --- a/m4/virt-driver-libxl.m4
> +++ b/m4/virt-driver-libxl.m4
> @@ -35,7 +35,7 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
>if test "x$with_libxl" = "xyes" ; then
>  LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight)
>  LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight)
> -  fi
> + fi
>  
>dnl pkgconfig file not found, fallback to lib probe
>if test "x$with_libxl" = "xno" ; then
> @@ -80,6 +80,10 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
>LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
>  ])
>  
> +dnl Check if libxl_domain_config_from_json is available for domXML to
> +dnl libxl_domain_config tests
> +LIBS="$LIBS -lxenlight -lxenctrl"
> +AC_CHECK_FUNCS([libxl_domain_config_from_json])
>  CFLAGS="$old_CFLAGS"
>  LIBS="$old_LIBS"
>fi
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 3e3d580..49b9d40 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -99,6 +99,7 @@ EXTRA_DIST =\
>   genericxml2xmlindata \
>   genericxml2xmloutdata \
>   interfaceschemadata \
> + libxlxml2domconfigdata \
>   lxcconf2xmldata \
>   lxcxml2xmldata \
>   lxcxml2xmloutdata \
> @@ -271,7 +272,8 @@ test_programs += xml2sexprtest sexpr2xmltest \
>  endif WITH_XEN
>  
>  if WITH_LIBXL
> -test_programs += xlconfigtest
> +test_programs += xlconfigtest libxlxml2domconfigtest
> +test_libraries += virmocklibxl.la
>  endif WITH_LIBXL
>  
>  if WITH_QEMU
> @@ -528,8 +530,20 @@ xlconfigtest_SOURCES = \
>   xlconfigtest.c testutilsxen.c testutilsxen.h \
>   testutils.c testutils.h
>  xlconfigtest_LDADD =$(libxl_LDADDS)
> +
> +libxlxml2domconfigtest_SOURCES = \
> + libxlxml2domconfigtest.c testutilsxen.c testutilsxen.h \
> + testutils.c testutils.h
> +libxlxml2domconfigtest_LDADD = $(libxl_LDADDS) $(LIBXML_LIBS)
&

Re: [libvirt] [PATCH 3/3] tests: check domain XML to libxl structures conversion

[Joao Martins]

On 06/29/2017 11:08 PM, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 29, 2017 at 10:06:39AM +0100, Joao Martins wrote:
>> On 06/29/2017 02:11 AM, Marek Marczykowski-Górecki wrote:
>>> libxl contains a method to dump libxl_domain_config in json format,
>>> which is really convenient for tests. Unfortunately it require
>>> libxl_ctx, which can be only created when running on Xen (wither in dom0
>>> or domU). Because of this, skip the test in other cases.
>>>
>>> For now, have just two tests, including just-introduced CPUID handling,
>>> but this commit introduces a framework for further tests of
>>> src/libxl/libxl_conf.c file.
>>
>> There's related work about this. You might wanna look at the recent Jim's 
>> series
>> (CC'in him) from a few months ago (see below). He ressurected danpb work on
>> these xml <-> libxl_domain_config conversion, and had a whole test suite for
>> that where your cpuid test would be better inserted? Patch series is here:
>>
>> https://www.redhat.com/archives/libvir-list/2017-February/msg01477.html
> 
> This looks like a much more complete solution. Indeed it would make
> sense to put this cpuid test there. Is there any reason why
> it isn't merged yet and there is no response in that thread?
> 
I guess it wasn't reviewed by folks. I was short on time with other deliverables
so that series slipped me and couldn't help much. Perhaps a resubmission to
restart discussion - It's really nice work and would greatly improve testing :)

Cheers,
Joao

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

Re: [libvirt] [PATCH 2/3] libxl: add support for CPUID features policy

[Joao Martins]

On 06/29/2017 09:39 AM, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 29, 2017 at 10:04:42AM +0200, Jiri Denemark wrote:
>> On Thu, Jun 29, 2017 at 03:11:42 +0200, Marek Marczykowski-Górecki wrote:
>>> Set CPU features in appropriate libxl structure.
>>> Use old "xend" syntax, because it allow control over any bit and libvirt
>>> already have API for translating features to appropriate cpuid bits. And
>>> also features naming in libxl do not match the one of libvirt in
>>> multiple cases.
>>
>> How does the new syntax look like? 
> 
> "host,tm=0,sse3=0"
> 
>> And would it be actually better? 
> 
> Maybe? But the new syntax use different names for many features (like
> pni vs sse3, or sep vs sysenter), so it would require some ugly
> translation table...
> What I would really like here, is to get list of bits specified with
> , _without_ those defined by . And maybe even
> without requiring  to be set at all.
> Another misleading thing about interpreting  here is, it doesn't
> mask out features not really present in that CPU. So, you get a CPU
> based on  but with many additional features.
> 
Two suggestions (the first one to hopefully complement current discussion):

1) Maybe there could be a driver config item to allow the Xend syntax (since
it's a rather fragile facility that allows all bits controlled)? Or else prefer
first libxl format through the translation table of features and use xend format
for this driver config such that non-supported features in libxl format fallback
to xend format instead? Probably this allows for best of both worlds (better
safety with libxl-format) yet higher flexibility/controllability with xend
format. Also I am not sure we should support models either - since our CPUID
view is restricted to host-{passthrough,model} only.

2) perhaps part of the code in this patch could be better placed at
xenconfig/xen_{xl,xm}.c since it's really two different formats of config? This
would also allow supporting Xen <-> Xml config file conversions.

Joao

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

Re: [libvirt] [PATCH 3/3] tests: check domain XML to libxl structures conversion

[Joao Martins]

On 06/29/2017 02:11 AM, Marek Marczykowski-Górecki wrote:
> libxl contains a method to dump libxl_domain_config in json format,
> which is really convenient for tests. Unfortunately it require
> libxl_ctx, which can be only created when running on Xen (wither in dom0
> or domU). Because of this, skip the test in other cases.
> 
> For now, have just two tests, including just-introduced CPUID handling,
> but this commit introduces a framework for further tests of
> src/libxl/libxl_conf.c file.

There's related work about this. You might wanna look at the recent Jim's series
(CC'in him) from a few months ago (see below). He ressurected danpb work on
these xml <-> libxl_domain_config conversion, and had a whole test suite for
that where your cpuid test would be better inserted? Patch series is here:

https://www.redhat.com/archives/libvir-list/2017-February/msg01477.html

> ---
>  tests/Makefile.am|   8 +-
>  tests/libxlxmltest.c | 232 -
>  2 files changed, 238 insertions(+), 2 deletions(-)
>  create mode 100644 tests/libxlxmltest.c
> 
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 19986dc..06c5c73 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -274,7 +274,7 @@ test_programs += xml2sexprtest sexpr2xmltest \
>  endif WITH_XEN
>  
>  if WITH_LIBXL
> -test_programs += xlconfigtest
> +test_programs += xlconfigtest libxlxmltest
>  endif WITH_LIBXL
>  
>  if WITH_QEMU
> @@ -528,9 +528,13 @@ libxl_LDADDS += $(LDADDS)
>  xlconfigtest_SOURCES = \
>   xlconfigtest.c testutilsxen.c testutilsxen.h \
>   testutils.c testutils.h
> +libxlxmltest_SOURCES = \
> + libxlxmltest.c testutilsxen.c testutilsxen.h \
> + testutils.c testutils.h
>  xlconfigtest_LDADD =$(libxl_LDADDS)
> +libxlxmltest_LDADD =$(libxl_LDADDS)
>  else ! WITH_LIBXL
> -EXTRA_DIST += xlconfigtest.c
> +EXTRA_DIST += xlconfigtest.c libxlxmltest.c
>  endif ! WITH_LIBXL
>  
>  QEMUMONITORTESTUTILS_SOURCES = \
> diff --git a/tests/libxlxmltest.c b/tests/libxlxmltest.c
> new file mode 100644
> index 000..7e11af4
> --- /dev/null
> +++ b/tests/libxlxmltest.c
> @@ -0,0 +1,232 @@
> +/*
> + * libxlxmltest.c: Test xl.cfg(5) <-> libxl_domain_config conversion
> + *
> + * Copyright (C) 2007, 2010-2011, 2014 Red Hat, Inc.
> + * Copyright (c) 2015 SUSE LINUX Products GmbH, Nuernberg, Germany.
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library.  If not, see
> + * .
> + *
> + * Author: Daniel P. Berrange 
> + * Author: Kiarie Kahurani 
> + * Author: Marek Marczykowski-Górecki 
> + *
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#ifdef WITH_YAJL2
> +# define HAVE_YAJL_V2 1
> +#endif
> +#include 
> +#include 
> +
> +#include "internal.h"
> +#include "datatypes.h"
> +#include "viralloc.h"
> +#include "virstring.h"
> +#include "testutils.h"
> +#include "testutilsxen.h"
> +#include "libxl/libxl_conf.h"
> +
> +#define VIR_FROM_THIS VIR_FROM_NONE
> +
> +static virCapsPtr caps;
> +static virDomainXMLOptionPtr xmlopt;
> +xentoollog_logger_stdiostream *logger;
> +libxl_ctx *ctx;
> +
> +
> +/*
> + * This function provides a mechanism to replace variables in test
> + * data files whose values are discovered at built time.
> + */
> +static char *
> +testReplaceVarsXML(const char *xml)
> +{
> +char *xmlcfgData;
> +char *replacedXML;
> +
> +if (virTestLoadFile(xml, ) < 0)
> +return NULL;
> +
> +replacedXML = virStringReplace(xmlcfgData, "/LIBXL_FIRMWARE_DIR",
> +   LIBXL_FIRMWARE_DIR);
> +
> +/* libxl driver checks for emulator existence */
> +replacedXML = virStringReplace(xmlcfgData, 
> "/usr/lib/xen/bin/qemu-system-i386",
> +   "/bin/true");
> +
> +VIR_FREE(xmlcfgData);
> +return replacedXML;
> +}
> +
> +/*
> + * Parses domXML to virDomainDef object, which is then converted to json
> + * config and compared with expected config.
> + */
> +static int
> +testCompareParseXML(const char *json, const char *xml, bool replaceVars)
> +{
> +char *gotjsonData = NULL;
> +virConfPtr conf = NULL;
> +virConnectPtr conn = NULL;
> +size_t wrote = 0;
> +int ret = -1;
> +virDomainDefPtr def = NULL;
> +char *replacedXML = NULL;
> +

Re: [libvirt] [RFC PATCH v1 4/4] xlconfigtest: add tests for numa cell sibling distances

[Joao Martins]

On 06/12/2017 07:54 PM, Wim Ten Have wrote:
> From: Wim ten Have 
> 
> Test a bidirectional xen-xl domxml to and from native for numa
> support administration as brought under this patch series.
> 
> Signed-off-by: Wim ten Have 
> ---
>  .../test-fullvirt-vnuma-nodistances.cfg| 26 +++
>  .../test-fullvirt-vnuma-nodistances.xml| 54 +++
>  tests/xlconfigdata/test-fullvirt-vnuma.cfg | 26 +++
>  tests/xlconfigdata/test-fullvirt-vnuma.xml | 81 
> ++
>  tests/xlconfigtest.c   |  4 ++
>  5 files changed, 191 insertions(+)
>  create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.cfg
>  create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.xml
>  create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.cfg
>  create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.xml
> 
> diff --git a/tests/xlconfigdata/test-fullvirt-vnuma-nodistances.cfg 
> b/tests/xlconfigdata/test-fullvirt-vnuma-nodistances.cfg
> new file mode 100644
> index 000..9871f21
> --- /dev/null
> +++ b/tests/xlconfigdata/test-fullvirt-vnuma-nodistances.cfg
> @@ -0,0 +1,26 @@
> +name = "XenGuest2"
> +uuid = "c7a5fdb2-cdaf-9455-926a-d65c16db1809"
> +maxmem = 8192
> +memory = 8192
> +vcpus = 8
> +pae = 1
> +acpi = 1
> +apic = 1
> +viridian = 0
> +rtc_timeoffset = 0
> +localtime = 0
> +on_poweroff = "destroy"
> +on_reboot = "restart"
> +on_crash = "restart"
> +device_model = "/usr/lib/xen/bin/qemu-system-i386"
> +sdl = 0
> +vnc = 1
> +vncunused = 1
> +vnclisten = "127.0.0.1"
> +vif = [ "mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000" ]
> +parallel = "none"
> +serial = "none"
> +builder = "hvm"
> +boot = "d"
> +vnuma = [ [ "pnode=0", "size=2048", "vcpus=0-1", "vdistances=10,21,21,21" ], 
> [ "pnode=1", "size=2048", "vcpus=2-3", "vdistances=21,10,21,21" ], [ 
> "pnode=2", "size=2048", "vcpus=4-5", "vdistances=21,21,10,21" ], [ "pnode=3", 
> "size=2048", "vcpus=6-7", "vdistances=21,21,21,10" ] ]
> +disk = [ 
> "format=raw,vdev=hda,access=rw,backendtype=phy,target=/dev/HostVG/XenGuest2" ]
> diff --git a/tests/xlconfigdata/test-fullvirt-vnuma-nodistances.xml 
> b/tests/xlconfigdata/test-fullvirt-vnuma-nodistances.xml
> new file mode 100644
> index 000..a576881
> --- /dev/null
> +++ b/tests/xlconfigdata/test-fullvirt-vnuma-nodistances.xml
> @@ -0,0 +1,54 @@
> +
> +  XenGuest2
> +  c7a5fdb2-cdaf-9455-926a-d65c16db1809
> +  8388608
> +  8388608
> +  8
> +  
> +hvm
> +/usr/lib/xen/boot/hvmloader
> +
> +  
> +  
> +
> +
> +
> +  
> +  
> +

We don't set/support topology info then it shouldn't be in the xml. Therefore
the test with nodistances will fail right? In that case  should be
removed then.

Albeit the other test doesn't have  element which is good :)

> +
> +  
> +  
> +  
> +  
> +
> +  
> +  
> +  destroy
> +  restart
> +  restart
> +  
> +/usr/lib/xen/bin/qemu-system-i386
> +
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> +  
> +  
> +  
> +
> +
> +
> +
> +  
> +
> +
> +  
> +
> +  
> +
> diff --git a/tests/xlconfigdata/test-fullvirt-vnuma.cfg 
> b/tests/xlconfigdata/test-fullvirt-vnuma.cfg
> new file mode 100644
> index 000..91e233a
> --- /dev/null
> +++ b/tests/xlconfigdata/test-fullvirt-vnuma.cfg
> @@ -0,0 +1,26 @@
> +name = "XenGuest2"
> +uuid = "c7a5fdb2-cdaf-9455-926a-d65c16db1809"
> +maxmem = 8192
> +memory = 8192
> +vcpus = 8
> +pae = 1
> +acpi = 1
> +apic = 1
> +viridian = 0
> +rtc_timeoffset = 0
> +localtime = 0
> +on_poweroff = "destroy"
> +on_reboot = "restart"
> +on_crash = "restart"
> +device_model = "/usr/lib/xen/bin/qemu-system-i386"
> +sdl = 0
> +vnc = 1
> +vncunused = 1
> +vnclisten = "127.0.0.1"
> +vif = [ "mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000" ]
> +parallel = "none"
> +serial = "none"
> +builder = "hvm"
> +boot = "d"
> +vnuma = [ [ "pnode=0", "size=2048", "vcpus=0-1", "vdistances=10,21,31,41" ], 
> [ "pnode=1", "size=2048", "vcpus=2-3", "vdistances=21,10,21,31" ], [ 
> "pnode=2", "size=2048", "vcpus=4-5", "vdistances=31,21,10,21" ], [ "pnode=3", 
> "size=2048", "vcpus=6-7", "vdistances=41,31,21,10" ] ]
> +disk = [ 
> "format=raw,vdev=hda,access=rw,backendtype=phy,target=/dev/HostVG/XenGuest2" ]
> diff --git a/tests/xlconfigdata/test-fullvirt-vnuma.xml 
> b/tests/xlconfigdata/test-fullvirt-vnuma.xml
> new file mode 100644
> index 000..5368b0d
> --- /dev/null
> +++ b/tests/xlconfigdata/test-fullvirt-vnuma.xml
> @@ -0,0 +1,81 @@
> +
> +  XenGuest2
> +  c7a5fdb2-cdaf-9455-926a-d65c16db1809
> +  8388608
> +  8388608
> +  8
> +  
> +hvm
> +/usr/lib/xen/boot/hvmloader
> +
> +  
> +  
> +
> +
> +
> +  
> +  
> +
> +  
> +
> +  
> +  
> +  
> +  
> +
> +  
> +  
> +   

Re: [libvirt] [PATCH V2 2/2] libxl: add default listen address for VNC and spice

[Joao Martins]

On 05/19/2017 11:33 PM, Jim Fehlig wrote:
> If a VNC listen address is not specified in domXML, libxl
> will default to 127.0.0.1, but this is never reflected in the domXML.
> In the case of spice, a missing listen address resulted in listening
> on all interfaces, i.e. '0.0.0.0'. If not specified, set the listen
> address in virDomainGraphicsDef struct to the libxl default when
> creating the frame buffer device. Additionally, set default spice
> listen address to 127.0.0.1.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>

Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>

> ---
> 
> V2: include setting the listen address for spice as well as VNC
> 
>  src/libxl/libxl_conf.c | 31 +--
>  1 file changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index 56bc09719..b04dffcfa 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -1227,13 +1227,18 @@ libxlMakeVfb(virPortAllocatorPtr graphicsports,
>  }
>  x_vfb->vnc.display = l_vfb->data.vnc.port - LIBXL_VNC_PORT_MIN;
>  
> -if ((glisten = virDomainGraphicsGetListen(l_vfb, 0)) &&
> -glisten->address) {
> -/* libxl_device_vfb_init() does VIR_STRDUP("127.0.0.1") */
> -VIR_FREE(x_vfb->vnc.listen);
> -if (VIR_STRDUP(x_vfb->vnc.listen, glisten->address) < 0)
> -return -1;
> +if ((glisten = virDomainGraphicsGetListen(l_vfb, 0))) {
> +if (glisten->address) {
> +/* libxl_device_vfb_init() does VIR_STRDUP("127.0.0.1") 
> */
> +VIR_FREE(x_vfb->vnc.listen);
> +if (VIR_STRDUP(x_vfb->vnc.listen, glisten->address) < 0)
> +return -1;
> +} else {
> +if (VIR_STRDUP(glisten->address, VIR_LOOPBACK_IPV4_ADDR) 
> < 0)
> +return -1;
> +}
>  }
> +
>  if (VIR_STRDUP(x_vfb->vnc.passwd, l_vfb->data.vnc.auth.passwd) < 
> 0)
>  return -1;
>  if (VIR_STRDUP(x_vfb->keymap, l_vfb->data.vnc.keymap) < 0)
> @@ -1335,10 +1340,16 @@ libxlMakeBuildInfoVfb(virPortAllocatorPtr 
> graphicsports,
>  }
>  b_info->u.hvm.spice.port = l_vfb->data.spice.port;
>  
> -if ((glisten = virDomainGraphicsGetListen(l_vfb, 0)) &&
> -glisten->address &&
> -VIR_STRDUP(b_info->u.hvm.spice.host, glisten->address) < 0)
> -return -1;
> +if ((glisten = virDomainGraphicsGetListen(l_vfb, 0))) {
> +if (glisten->address) {
> +if (VIR_STRDUP(b_info->u.hvm.spice.host, glisten->address) < 
> 0)
> +return -1;
> +} else {
> +if (VIR_STRDUP(b_info->u.hvm.spice.host, 
> VIR_LOOPBACK_IPV4_ADDR) < 0 ||
> +VIR_STRDUP(glisten->address, VIR_LOOPBACK_IPV4_ADDR) < 0)
> +return -1;
> +}
> +}
>  
>  if (VIR_STRDUP(b_info->u.hvm.keymap, l_vfb->data.spice.keymap) < 0)
>  return -1;
> 

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

Re: [libvirt] [PATCH V2 1/2] maint: define a macro for IPv4 loopback address

[Joao Martins]

On 05/19/2017 11:33 PM, Jim Fehlig wrote:
> Use a macro instead of hardcoding "127.0.0.1" throughout the
> sources.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>

Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>

> ---
>  src/internal.h   | 2 ++
>  src/qemu/qemu_conf.c | 4 ++--
>  src/util/virsocketaddr.c | 4 ++--
>  src/vz/vz_sdk.c  | 2 +-
>  4 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/src/internal.h b/src/internal.h
> index 9e7ef553d..03a973ccd 100644
> --- a/src/internal.h
> +++ b/src/internal.h
> @@ -79,6 +79,8 @@
>  #  define INET_ADDRSTRLEN 16
>  # endif
>  
> +# define VIR_LOOPBACK_IPV4_ADDR "127.0.0.1"
> +
>  /* String equality tests, suggested by Jim Meyering. */
>  # define STREQ(a, b) (strcmp(a, b) == 0)
>  # define STRCASEEQ(a, b) (c_strcasecmp(a, b) == 0)
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 1b704daa5..19ddf787d 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -250,10 +250,10 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
> privileged)
> SYSCONFDIR "/pki/qemu") < 0)
>  goto error;
>  
> -if (VIR_STRDUP(cfg->vncListen, "127.0.0.1") < 0)
> +if (VIR_STRDUP(cfg->vncListen, VIR_LOOPBACK_IPV4_ADDR) < 0)
>  goto error;
>  
> -if (VIR_STRDUP(cfg->spiceListen, "127.0.0.1") < 0)
> +if (VIR_STRDUP(cfg->spiceListen, VIR_LOOPBACK_IPV4_ADDR) < 0)
>  goto error;
>  
>  /*
> diff --git a/src/util/virsocketaddr.c b/src/util/virsocketaddr.c
> index 41f75d5c2..9dffbc736 100644
> --- a/src/util/virsocketaddr.c
> +++ b/src/util/virsocketaddr.c
> @@ -383,11 +383,11 @@ virSocketAddrFormatFull(const virSocketAddr *addr,
>   * nicely for UNIX sockets */
>  if (addr->data.sa.sa_family == AF_UNIX) {
>  if (withService) {
> -if (virAsprintf(, "127.0.0.1%s0",
> +if (virAsprintf(, VIR_LOOPBACK_IPV4_ADDR"%s0",
>  separator ? separator : ":") < 0)
>  goto error;
>  } else {
> -if (VIR_STRDUP(addrstr, "127.0.0.1") < 0)
> +if (VIR_STRDUP(addrstr, VIR_LOOPBACK_IPV4_ADDR) < 0)
>  goto error;
>  }
>  return addrstr;
> diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
> index 4d2c6b0f1..4fab3b9bf 100644
> --- a/src/vz/vz_sdk.c
> +++ b/src/vz/vz_sdk.c
> @@ -3084,7 +3084,7 @@ static int prlsdkApplyGraphicsParams(PRL_HANDLE sdkdom,
>  
>  glisten = virDomainGraphicsGetListen(gr, 0);
>  pret = PrlVmCfg_SetVNCHostName(sdkdom, glisten && glisten->address ?
> -   glisten->address : "127.0.0.1");
> +   glisten->address : 
> VIR_LOOPBACK_IPV4_ADDR);
>  prlsdkCheckRetGoto(pret, cleanup);
>  
>  ret = 0;
> 

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

Re: [libvirt] [PATCH] libxl: add default VNC listen address

[Joao Martins]

On 05/17/2017 10:38 PM, Jim Fehlig wrote:
> If a VNC listen address is not specified in domXML, libxl will
> default to 127.0.0.1, but this is never reflected in the domXML.
> If not specified, set the listen address in virDomainGraphicsDef
> struct to the libxl default when creating the frame buffer device.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1334562
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
>
Just a nit (more of a suggestion in the future), "127.0.0.1" seems to be
hardcoded all over libvirt AFAIK (e.g. qemu driver, socketaddr.c) , maybe
defining a macro in a well defined place would be better.

Other than that,

Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>

This fix should silence that message virt-viewer warnings. nice :)

Joao

> ---
>  src/libxl/libxl_conf.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index 56bc09719..0c5d7a700 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -1227,12 +1227,16 @@ libxlMakeVfb(virPortAllocatorPtr graphicsports,
>  }
>  x_vfb->vnc.display = l_vfb->data.vnc.port - LIBXL_VNC_PORT_MIN;
>  
> -if ((glisten = virDomainGraphicsGetListen(l_vfb, 0)) &&
> -glisten->address) {
> -/* libxl_device_vfb_init() does VIR_STRDUP("127.0.0.1") */
> -VIR_FREE(x_vfb->vnc.listen);
> -if (VIR_STRDUP(x_vfb->vnc.listen, glisten->address) < 0)
> -return -1;
> +if ((glisten = virDomainGraphicsGetListen(l_vfb, 0))) {
> +if (glisten->address) {
> +/* libxl_device_vfb_init() does VIR_STRDUP("127.0.0.1") 
> */
> +VIR_FREE(x_vfb->vnc.listen);
> +if (VIR_STRDUP(x_vfb->vnc.listen, glisten->address) < 0)
> +return -1;
> +} else {
> +if (VIR_STRDUP(glisten->address, "127.0.0.1") < 0)
> +return -1;
> +}
>  }
>  if (VIR_STRDUP(x_vfb->vnc.passwd, l_vfb->data.vnc.auth.passwd) < 
> 0)
>  return -1;
> 

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

Re: [libvirt] [PATCH v2] libxl: report numa sibling distances on host capabilities

[Joao Martins]

On 05/09/2017 07:06 PM, Wim Ten Have wrote:
> From: Wim ten Have <wim.ten.h...@oracle.com>
> 
> When running on a NUMA machine, populate the sibling node
> and distance information using data supplied by Xen.
> 
> With locality distances information, under Xen, new host
> capabilities would like:
> 
> 
>   
> 
>   263902380
>   
> 
> 
>   
>   ...
> 
> ...
>   
>   ...
> 
> 
> Signed-off-by: Wim ten Have <wim.ten.h...@oracle.com>

I had reviewed this internally so FWIW,

Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>

>  src/libxl/libxl_capabilities.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c
> index 839a2ee..e095920 100644
> --- a/src/libxl/libxl_capabilities.c
> +++ b/src/libxl/libxl_capabilities.c
> @@ -247,8 +247,9 @@ libxlCapsInitNuma(libxl_ctx *ctx, virCapsPtr caps)
>  {
>  libxl_numainfo *numa_info = NULL;
>  libxl_cputopology *cpu_topo = NULL;
> -int nr_nodes = 0, nr_cpus = 0;
> +int nr_nodes = 0, nr_cpus = 0, nr_siblings = 0;
>  virCapsHostNUMACellCPUPtr *cpus = NULL;
> +virCapsHostNUMACellSiblingInfoPtr siblings = NULL;
>  int *nr_cpus_node = NULL;
>  size_t i;
>  int ret = -1;
> @@ -322,10 +323,23 @@ libxlCapsInitNuma(libxl_ctx *ctx, virCapsPtr caps)
>  if (numa_info[i].size == LIBXL_NUMAINFO_INVALID_ENTRY)
>  continue;
>  
> +nr_siblings = numa_info[i].num_dists;
> +if (nr_siblings) {
> +size_t j;
> +
> +if (VIR_ALLOC_N(siblings, nr_siblings) < 0)
> +goto cleanup;
> +
> +for (j = 0; j < nr_siblings; j++) {
> +siblings[j].node = j;
> +siblings[j].distance = numa_info[i].dists[j];
> +}
> +}
> +
>  if (virCapabilitiesAddHostNUMACell(caps, i,
> numa_info[i].size / 1024,
> nr_cpus_node[i], cpus[i],
> -   0, NULL,
> +   nr_siblings, siblings,
> 0, NULL) < 0) {
>  virCapabilitiesClearHostNUMACellCPUTopology(cpus[i],
>  nr_cpus_node[i]);
> @@ -343,6 +357,7 @@ libxlCapsInitNuma(libxl_ctx *ctx, virCapsPtr caps)
>  for (i = 0; cpus && i < nr_nodes; i++)
>  VIR_FREE(cpus[i]);
>  virCapabilitiesFreeNUMAInfo(caps);
> +VIR_FREE(siblings);
>  }
>  
>  VIR_FREE(cpus);
> 

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

Re: [libvirt] [PATCH v1 0/3] libxl: nestedhvm support

[Joao Martins]

On 03/08/2017 03:07 PM, Daniel P. Berrange wrote:
> On Wed, Mar 08, 2017 at 03:09:11PM +0000, Joao Martins wrote:
>> On 03/08/2017 02:13 PM, Daniel P. Berrange wrote:
>>> On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
>>>> From: Wim ten Have <wim.ten.h...@oracle.com>
>>>>
>>>> This patch enhances host-passthrough capability to advertise the
>>>> required vendor CPU virtualization feature which will be used to
>>>> enable 'nestedhvm' in the libxl driver.
>>>>
>>>> For Intel virtualization (VT-x)
>>>> ..
>>>>   
>>>> 
>>>>   
>>>>
>>>> For AMD virtualization (AMD-V)
>>>> ..
>>>>   
>>>> 
>>>>   
>>>
>>> If using host-passthrough or host-model, and the host's CPU includes
>>> vmx or svm, then I would expecte nested-HVM to be enabled, without
>>> needing any extra  flag in the XML. That would match the
>>> semantics used with the QEMU driver.
>>>
>>> The only time we would need to use  is if using mode=custom
>>> along with a named CPU model which lacks vmx/svm flags.
>> Ah OK - I was kinda off unclear on that. So using host-passthrough should be
>> enough then. (while making sure libxl checks if host->cpu does have vmx or 
>> svm
>> in its features)
>>
>>> BTW, I wonder how hard it would be to wire up the libxl driver to use
>>> the CPU model infrastructure in src/cpu ? It feels a little odd to use
>>> XML  if we're not then making sure it
>>> actually uses host-passthrough when configuring the guest.
>> While xen libxl do allow to mangle the cpuid, it is meant for disabling 
>> features
>> at this point. libxl follows a "host-model" first, meaning the default is to
>> expose as much as features as possible to the guest (depending on whether 
>> it's
>> PV or HVM). However, nested virt is a slightly special case since the 
>> toolstack
>> will do more than simply unmasking vmx/svm bits (actually within libxl, a 
>> sysctl
>> to Xen is performed to enable nested virt to the domain, in which case libxc
>> will handle any vendor specific bits). IOW, even when we improve libxl cpuid
>> policy management to the point we can wire up to libvirt cpu model
>> infrastruture, we would still need to handle the nestedhvm special case 
>> (which
>> btw this field would work even for ARM whenever supported).
> 
> Yep, I see. So with libxl using host-model by default, then
> 
>  - If the host CPU includes svm/vmx, turn on nested virt in the guest
>  - Allow use of  to block nested
>virt in the guest, even if available in host CPU

Cool, thanks!

Joao

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

Re: [libvirt] [PATCH v1 0/3] libxl: nestedhvm support

[Joao Martins]

On 03/08/2017 02:13 PM, Daniel P. Berrange wrote:
> On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
>> From: Wim ten Have 
>>
>> This patch enhances host-passthrough capability to advertise the
>> required vendor CPU virtualization feature which will be used to
>> enable 'nestedhvm' in the libxl driver.
>>
>> For Intel virtualization (VT-x)
>> ..
>>   
>> 
>>   
>>
>> For AMD virtualization (AMD-V)
>> ..
>>   
>> 
>>   
> 
> If using host-passthrough or host-model, and the host's CPU includes
> vmx or svm, then I would expecte nested-HVM to be enabled, without
> needing any extra  flag in the XML. That would match the
> semantics used with the QEMU driver.
> 
> The only time we would need to use  is if using mode=custom
> along with a named CPU model which lacks vmx/svm flags.
Ah OK - I was kinda off unclear on that. So using host-passthrough should be
enough then. (while making sure libxl checks if host->cpu does have vmx or svm
in its features)

> BTW, I wonder how hard it would be to wire up the libxl driver to use
> the CPU model infrastructure in src/cpu ? It feels a little odd to use
> XML  if we're not then making sure it
> actually uses host-passthrough when configuring the guest.
While xen libxl do allow to mangle the cpuid, it is meant for disabling features
at this point. libxl follows a "host-model" first, meaning the default is to
expose as much as features as possible to the guest (depending on whether it's
PV or HVM). However, nested virt is a slightly special case since the toolstack
will do more than simply unmasking vmx/svm bits (actually within libxl, a sysctl
to Xen is performed to enable nested virt to the domain, in which case libxc
will handle any vendor specific bits). IOW, even when we improve libxl cpuid
policy management to the point we can wire up to libvirt cpu model
infrastruture, we would still need to handle the nestedhvm special case (which
btw this field would work even for ARM whenever supported).

Joao

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

Re: [libvirt] [PATCH RFC 3/4] libxl: implement qemu-agent-command

[Joao Martins]

On 03/03/2017 12:15 AM, Jim Fehlig wrote:
> On 03/02/2017 11:46 AM, Jim Fehlig wrote:
>> On 02/08/2017 09:44 AM, Joao Martins wrote:
>>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
> 
> Opps, forgot to mention that it would be helpful if the commit message 
> contained 
> info on what Xen versions are supported and example config for the agent's 
> channel device.
Yeap, will add it.

> BTW, does this work with PV domUs that have a qemu process?
Yeap, it works.

> 
> Regards,
> Jim
> 
>>> ---
>>>  src/libxl/libxl_domain.c | 239 
>>> ++-
>>>  src/libxl/libxl_domain.h |  16 
>>>  src/libxl/libxl_driver.c |  51 ++
>>>  3 files changed, 305 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
>>> index ed73cd2..6bdd0ec 100644
>>> --- a/src/libxl/libxl_domain.c
>>> +++ b/src/libxl/libxl_domain.c
>>> @@ -782,6 +782,12 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
>>>  }
>>>  }
>>>
>>> +if (priv->agent) {
>>> +qemuAgentClose(priv->agent);
>>> +priv->agent = NULL;
>>> +priv->agentError = false;
>>> +}
>>> +
>>>  if ((vm->def->nnets)) {
>>>  size_t i;
>>>
>>> @@ -940,6 +946,228 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config
>>> *d_config)
>>>  return -1;
>>>  }
>>>
>>> +/*
>>> + * This is a callback registered with a qemuAgentPtr instance,
>>> + * and to be invoked when the agent console hits an end of file
>>> + * condition, or error, thus indicating VM shutdown should be
>>> + * performed
>>> + */
>>> +static void
>>> +libxlHandleAgentEOF(qemuAgentPtr agent,
>>> +  virDomainObjPtr vm)
>>
>> Whitespace is off.
>>
>>> +{
>>> +libxlDomainObjPrivatePtr priv;
>>> +
>>> +VIR_DEBUG("Received EOF from agent on %p '%s'", vm, vm->def->name);
>>> +
>>> +virObjectLock(vm);
>>> +
>>> +priv = vm->privateData;
>>> +
>>> +if (!priv->agent) {
>>> +VIR_DEBUG("Agent freed already");
>>> +goto unlock;
>>> +}
>>> +
>>> +qemuAgentClose(agent);
>>> +priv->agent = NULL;
>>
>> Should priv->agentError be reset to false?
>>
>>> +
>>> + unlock:
>>> +virObjectUnlock(vm);
>>> +return;
>>> +}
>>> +
>>> +
>>> +/*
>>> + * This is invoked when there is some kind of error
>>> + * parsing data to/from the agent. The VM can continue
>>> + * to run, but no further agent commands will be
>>> + * allowed
>>> + */
>>> +static void
>>> +libxlHandleAgentError(qemuAgentPtr agent ATTRIBUTE_UNUSED,
>>> +virDomainObjPtr vm)
>>
>> Whitespace is off here too, and in a few other places below that I'll stop
>> nagging about.
>>
>>> +{
>>> +libxlDomainObjPrivatePtr priv;
>>> +
>>> +VIR_DEBUG("Received error from agent on %p '%s'", vm, vm->def->name);
>>> +
>>> +virObjectLock(vm);
>>> +
>>> +priv = vm->privateData;
>>> +
>>> +priv->agentError = true;
>>> +
>>> +virObjectUnlock(vm);
>>> +}
>>> +
>>> +static void libxlHandleAgentDestroy(qemuAgentPtr agent,
>>> +  virDomainObjPtr vm)
>>> +{
>>> +VIR_DEBUG("Received destroy agent=%p vm=%p", agent, vm);
>>> +
>>> +virObjectUnref(vm);
>>> +}
>>> +
>>> +static qemuAgentCallbacks agentCallbacks = {
>>> +.destroy = libxlHandleAgentDestroy,
>>> +.eofNotify = libxlHandleAgentEOF,
>>> +.errorNotify = libxlHandleAgentError,
>>> +};
>>> +
>>> +static virDomainChrDefPtr
>>> +libxlFindAgentConfig(virDomainDefPtr def)
>>> +{
>>> +size_t i;
>>> +
>>> +for (i = 0; i < def->nchannels; i++) {
>>> +virDomainChrDefPtr channel = def->channels[i];
>>> +
>>> +if (channel->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN)
>>> +continue;
>&

Re: [libvirt] [PATCH RFC 3/4] libxl: implement qemu-agent-command

[Joao Martins]

On 03/02/2017 06:46 PM, Jim Fehlig wrote:
> On 02/08/2017 09:44 AM, Joao Martins wrote:
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>> ---
Sorry - being an RFC I let myself be a little too clumsy on the commit messages.
This was meant to have at least the bits mentioned in the cover letter.

>>  src/libxl/libxl_domain.c | 239 
>> ++-
>>  src/libxl/libxl_domain.h |  16 
>>  src/libxl/libxl_driver.c |  51 ++
>>  3 files changed, 305 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
>> index ed73cd2..6bdd0ec 100644
>> --- a/src/libxl/libxl_domain.c
>> +++ b/src/libxl/libxl_domain.c
>> @@ -782,6 +782,12 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
>>  }
>>  }
>>
>> +if (priv->agent) {
>> +qemuAgentClose(priv->agent);
>> +priv->agent = NULL;
>> +priv->agentError = false;
>> +}
>> +
>>  if ((vm->def->nnets)) {
>>  size_t i;
>>
>> @@ -940,6 +946,228 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config 
>> *d_config)
>>  return -1;
>>  }
>>
>> +/*
>> + * This is a callback registered with a qemuAgentPtr instance,
>> + * and to be invoked when the agent console hits an end of file
>> + * condition, or error, thus indicating VM shutdown should be
>> + * performed
>> + */
>> +static void
>> +libxlHandleAgentEOF(qemuAgentPtr agent,
>> +  virDomainObjPtr vm)
> 
> Whitespace is off.
/nods

>> +{
>> +libxlDomainObjPrivatePtr priv;
>> +
>> +VIR_DEBUG("Received EOF from agent on %p '%s'", vm, vm->def->name);
>> +
>> +virObjectLock(vm);
>> +
>> +priv = vm->privateData;
>> +
>> +if (!priv->agent) {
>> +VIR_DEBUG("Agent freed already");
>> +goto unlock;
>> +}
>> +
>> +qemuAgentClose(agent);
>> +priv->agent = NULL;
> 
> Should priv->agentError be reset to false?
Yeap.

> 
>> +
>> + unlock:
>> +virObjectUnlock(vm);
>> +return;
>> +}
>> +
>> +
>> +/*
>> + * This is invoked when there is some kind of error
>> + * parsing data to/from the agent. The VM can continue
>> + * to run, but no further agent commands will be
>> + * allowed
>> + */
>> +static void
>> +libxlHandleAgentError(qemuAgentPtr agent ATTRIBUTE_UNUSED,
>> +virDomainObjPtr vm)
> 
> Whitespace is off here too, and in a few other places below that I'll stop 
> nagging about.
Will fix those.

>> +{
>> +libxlDomainObjPrivatePtr priv;
>> +
>> +VIR_DEBUG("Received error from agent on %p '%s'", vm, vm->def->name);
>> +
>> +virObjectLock(vm);
>> +
>> +priv = vm->privateData;
>> +
>> +priv->agentError = true;
>> +
>> +virObjectUnlock(vm);
>> +}
>> +
>> +static void libxlHandleAgentDestroy(qemuAgentPtr agent,
>> +  virDomainObjPtr vm)
>> +{
>> +VIR_DEBUG("Received destroy agent=%p vm=%p", agent, vm);
>> +
>> +virObjectUnref(vm);
>> +}
>> +
>> +static qemuAgentCallbacks agentCallbacks = {
>> +.destroy = libxlHandleAgentDestroy,
>> +.eofNotify = libxlHandleAgentEOF,
>> +.errorNotify = libxlHandleAgentError,
>> +};
>> +
>> +static virDomainChrDefPtr
>> +libxlFindAgentConfig(virDomainDefPtr def)
>> +{
>> +size_t i;
>> +
>> +for (i = 0; i < def->nchannels; i++) {
>> +virDomainChrDefPtr channel = def->channels[i];
>> +
>> +if (channel->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN)
>> +continue;
>> +
>> +if (STREQ_NULLABLE(channel->target.name, "org.qemu.guest_agent.0"))
>> +return channel;
>> +}
>> +
>> +return NULL;
>> +}
>> +
>> +bool
>> +libxlDomainAgentAvailable(virDomainObjPtr vm, bool reportError)
> 
> Is the reportError parameter needed? The callers in this patch and 4/4 pass 
> 'true'.
Probably that should be removed. Being always true it is redundant.

>> +{
>> +libxlDomainObjPrivatePtr priv = vm->privateData;
>> +
>> +if (virDomainObjGetState(vm, NULL) != VIR_DOMAIN_RUNNING) {
>> +if (reportError) {
>

Re: [libvirt] [PATCH RFC 2/4] qemu_agent: ignore requests echoed back by guest

[Joao Martins]

On 03/02/2017 06:16 PM, Daniel P. Berrange wrote:
> On Thu, Mar 02, 2017 at 11:10:10AM -0700, Jim Fehlig wrote:
>> On 02/08/2017 09:44 AM, Joao Martins wrote:
>>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>>
>> Since it wasn't needed before, I think it is helpful for the commit message
>> to describe why the change is needed now.
> 
> I'm open to being convinced otherwise, but I'd say that if the guest
> is echo'ing back commands the host sends, then the guest is broken
> and we shouldn't workaround that in libvirt. Or perhaps something
> about the hypervisor data channel over which the guest agent is
> running is running.
>
> Seeing data echo'd back suggests use of a PTY which has not been
> put into raw mode, or something like that.

OK, Thanks for the pointers.

This is one of the biggest reasons this is an RFC, as I haven't investigated
this properly yet. My gut feeling was that this could be on the device model
side (i.e. qemu) or even xenconsole handling side - and this was happening on
both socket and pty channel types. Anyhow, I can't make the argument/case for
inclusion of this patch yet, but being a one-liner I thought of including it for
purposes of a working RFC/prototype.

Joao

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

Re: [libvirt] [PATCH RFC 1/4] qemu_agent: move agent into util

[Joao Martins]

On 03/03/2017 11:35 AM, Daniel P. Berrange wrote:
> On Fri, Mar 03, 2017 at 11:36:25AM +0000, Joao Martins wrote:
>>
>>
>> On 03/02/2017 05:58 PM, Jim Fehlig wrote:
>>> Sorry for the review delay.
>>>
>>> On 02/08/2017 09:44 AM, Joao Martins wrote:
>>>> As it could be shared with libxl which now allows channels to
>>>> be created. Also changed filename to match others in the same
>>>> directory namely to virqemuagent.{h,c}
>>>>
>>>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>>>> ---
>>>>  po/POTFILES.in   |2 +-
>>>>  src/Makefile.am  |2 +-
>>>>  src/libvirt_private.syms |   21 +
>>>>  src/qemu/qemu_agent.c| 2248 
>>>> --
>>>>  src/qemu/qemu_agent.h|  123 ---
>>>>  src/qemu/qemu_domain.h   |2 +-
>>>>  src/qemu/qemu_driver.c   |2 +-
>>>>  src/util/virqemuagent.c  | 2248 
>>>> ++
>>>>  src/util/virqemuagent.h  |  123 +++
>>>>  tests/qemuagenttest.c|2 +-
>>>>  tests/qemumonitortestutils.c |2 +-
>>>>  tests/qemumonitortestutils.h |2 +-
>>>>  12 files changed, 2399 insertions(+), 2378 deletions(-)
>>>>  delete mode 100644 src/qemu/qemu_agent.c
>>>>  delete mode 100644 src/qemu/qemu_agent.h
>>>>  create mode 100644 src/util/virqemuagent.c
>>>>  create mode 100644 src/util/virqemuagent.h
>>>
>>> I hope others will opine on this change. It seems reasonable to me and I'm 
>>> surprised the qemu driver only needed tiny changes to accommodate moving 
>>> all 
>>> this code.
>>
>> Yeap, I too was surprised on how the changes were non disruptive wrt to qemu
>> driver :)
>>
>>>
>>> [...]
>>>> diff --git a/src/util/virqemuagent.h b/src/util/virqemuagent.h
>>>> new file mode 100644
>>>> index 000..2e81020
>>>> --- /dev/null
>>>> +++ b/src/util/virqemuagent.h
>>>> @@ -0,0 +1,123 @@
>>>> +/*
>>>> + * virqemuagent.h: interaction with QEMU guest agent
>>>> + *
>>>> + * Copyright (C) 2006-2012 Red Hat, Inc.
>>>> + * Copyright (C) 2006 Daniel P. Berrange
>>>> + *
>>>> + * This library is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU Lesser General Public
>>>> + * License as published by the Free Software Foundation; either
>>>> + * version 2.1 of the License, or (at your option) any later version.
>>>> + *
>>>> + * This library is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>> + * Lesser General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU Lesser General Public
>>>> + * License along with this library.  If not, see
>>>> + * <http://www.gnu.org/licenses/>.
>>>> + *
>>>> + * Author: Daniel P. Berrange <berra...@redhat.com>
>>>> + */
>>>> +
>>>> +
>>>> +#ifndef __QEMU_AGENT_H__
>>>> +# define __QEMU_AGENT_H__
>>>> +
>>>> +# include "internal.h"
>>>> +# include "domain_conf.h"
>>>
>>> ISTR a recent discussion on the list frowning on using code from src/conf 
>>> in 
>>> src/util, although virthostdev.h also includes domain_conf.h.
>>>
>>> BTW, compilation fails here
>>>
>>> In file included from util/virqemuagent.c:35:0:
>>> util/virqemuagent.h:29:26: fatal error: domain_conf.h: No such file or 
>>> directory
>>>   # include "domain_conf.h"
>>>
>> Hmm, will have to fix it for v1. This series were applied on top of commit
>> 2841e67 ("qemu: propagate bridge MTU into qemu "host_mtu" option") and I 
>> didn't
>> observe compilation  issues (neither make {syntax-check,check} IIRC).
>>
>>>> +
>>>> +typedef struct _qemuAgent qemuAgent;
>>>> +typedef qemuAgent *qemuAgentPtr;
>>>> +
>>>> +typedef struct _qemuAgentCallbacks qemuAgentCallbacks;
>>>> +typedef qemuAgentCallbacks *qemuAgentCal

Re: [libvirt] [PATCH RFC 2/4] qemu_agent: ignore requests echoed back by guest

[Joao Martins]

On 03/02/2017 06:10 PM, Jim Fehlig wrote:
> On 02/08/2017 09:44 AM, Joao Martins wrote:
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
> 
> Since it wasn't needed before, I think it is helpful for the commit message 
> to 
> describe why the change is needed now.

True, my apologies. I should have included at least the sentence I had on the
cover letter regarding this commit (same for patch 3).

>> ---
>>  src/util/virqemuagent.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/util/virqemuagent.c b/src/util/virqemuagent.c
>> index caabae0..ffb3489 100644
>> --- a/src/util/virqemuagent.c
>> +++ b/src/util/virqemuagent.c
>> @@ -333,7 +333,8 @@ qemuAgentIOProcessLine(qemuAgentPtr mon,
>>  goto cleanup;
>>  }
>>
>> -if (virJSONValueObjectHasKey(obj, "QMP") == 1) {
>> +if (virJSONValueObjectHasKey(obj, "QMP") == 1 ||
>> +virJSONValueObjectHasKey(obj, "execute") == 1) {
> 
> And a brief comment in the code, e.g. along the lines of the commit summary.

/nods

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

Re: [libvirt] [PATCH RFC 1/4] qemu_agent: move agent into util

[Joao Martins]

On 03/02/2017 05:58 PM, Jim Fehlig wrote:
> Sorry for the review delay.
> 
> On 02/08/2017 09:44 AM, Joao Martins wrote:
>> As it could be shared with libxl which now allows channels to
>> be created. Also changed filename to match others in the same
>> directory namely to virqemuagent.{h,c}
>>
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>> ---
>>  po/POTFILES.in   |2 +-
>>  src/Makefile.am  |2 +-
>>  src/libvirt_private.syms |   21 +
>>  src/qemu/qemu_agent.c| 2248 
>> --
>>  src/qemu/qemu_agent.h|  123 ---
>>  src/qemu/qemu_domain.h   |2 +-
>>  src/qemu/qemu_driver.c   |2 +-
>>  src/util/virqemuagent.c  | 2248 
>> ++
>>  src/util/virqemuagent.h  |  123 +++
>>  tests/qemuagenttest.c|2 +-
>>  tests/qemumonitortestutils.c |2 +-
>>  tests/qemumonitortestutils.h |2 +-
>>  12 files changed, 2399 insertions(+), 2378 deletions(-)
>>  delete mode 100644 src/qemu/qemu_agent.c
>>  delete mode 100644 src/qemu/qemu_agent.h
>>  create mode 100644 src/util/virqemuagent.c
>>  create mode 100644 src/util/virqemuagent.h
> 
> I hope others will opine on this change. It seems reasonable to me and I'm 
> surprised the qemu driver only needed tiny changes to accommodate moving all 
> this code.

Yeap, I too was surprised on how the changes were non disruptive wrt to qemu
driver :)

> 
> [...]
>> diff --git a/src/util/virqemuagent.h b/src/util/virqemuagent.h
>> new file mode 100644
>> index 000..2e81020
>> --- /dev/null
>> +++ b/src/util/virqemuagent.h
>> @@ -0,0 +1,123 @@
>> +/*
>> + * virqemuagent.h: interaction with QEMU guest agent
>> + *
>> + * Copyright (C) 2006-2012 Red Hat, Inc.
>> + * Copyright (C) 2006 Daniel P. Berrange
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with this library.  If not, see
>> + * <http://www.gnu.org/licenses/>.
>> + *
>> + * Author: Daniel P. Berrange <berra...@redhat.com>
>> + */
>> +
>> +
>> +#ifndef __QEMU_AGENT_H__
>> +# define __QEMU_AGENT_H__
>> +
>> +# include "internal.h"
>> +# include "domain_conf.h"
> 
> ISTR a recent discussion on the list frowning on using code from src/conf in 
> src/util, although virthostdev.h also includes domain_conf.h.
> 
> BTW, compilation fails here
> 
> In file included from util/virqemuagent.c:35:0:
> util/virqemuagent.h:29:26: fatal error: domain_conf.h: No such file or 
> directory
>   # include "domain_conf.h"
> 
Hmm, will have to fix it for v1. This series were applied on top of commit
2841e67 ("qemu: propagate bridge MTU into qemu "host_mtu" option") and I didn't
observe compilation  issues (neither make {syntax-check,check} IIRC).

>> +
>> +typedef struct _qemuAgent qemuAgent;
>> +typedef qemuAgent *qemuAgentPtr;
>> +
>> +typedef struct _qemuAgentCallbacks qemuAgentCallbacks;
>> +typedef qemuAgentCallbacks *qemuAgentCallbacksPtr;
>> +struct _qemuAgentCallbacks {
>> +void (*destroy)(qemuAgentPtr mon,
>> +virDomainObjPtr vm);
>> +void (*eofNotify)(qemuAgentPtr mon,
>> +  virDomainObjPtr vm);
>> +void (*errorNotify)(qemuAgentPtr mon,
>> +virDomainObjPtr vm);
>> +};
>> +
>> +
>> +qemuAgentPtr qemuAgentOpen(virDomainObjPtr vm,
>> +   const virDomainChrSourceDef *config,
>> +   qemuAgentCallbacksPtr cb);
>> +
>> +void qemuAgentClose(qemuAgentPtr mon);
> 
> Other files in src/util prefix structs and functions with "vir". I'm not sure 
> how picky folks are about that. If the consensus is towards the "vir" prefix, 
> perhaps it would be easier done with a follow-up after the move?
Yeah I noticed the pattern. Though given the big move of code into util making
as a follow-up patch would easy review perhaps.

> 
> Thanks a lot for working on this feature! It would be cool to get it in the 
> 3.2.0 release.
> 
> Regards,
> Jim
> 

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

[libvirt] [PATCH] libxl: fix coverity issues introduced by 6a95edf

[Joao Martins]

As discussed here [0][1] Coverity reported two issues:

- On libxlDomainMigrationPrepareTunnel3 @@mig will be leaked on failures
after sucessfull call libxlDomainMigrationPrepareAny hence we free it.

Setting mig = NULL after @mig is assigned plus adding libxlMigrationCookieFree
on error paths addresses the issue. In case virThreadCreate fails,
unref of args frees the cookie on dispose function 
(libxlMigrationDstArgsDispose)

- On libxlMigrationStartTunnel @tc would be leaked.

Fixed by correctly saving the newly allocated @tc onto @tnl such that
libxlMigrationStopTunnel would free it up.

[0] https://www.redhat.com/archives/libvir-list/2017-February/msg00791.html
[1] https://www.redhat.com/archives/libvir-list/2017-February/msg00833.html

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
Cc: John Ferlan <jfer...@redhat.com>
Cc: Jim Fehlig <jfeh...@suse.com>
---
 src/libxl/libxl_migration.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index ba1ca5c..fb833d1 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -617,6 +617,8 @@ libxlDomainMigrationPrepareTunnel3(virConnectPtr dconn,
 /* Receive from pipeOut */
 args->recvfd = dataFD[0];
 args->nsocks = 0;
+mig = NULL;
+
 if (virThreadCreate(, false, libxlDoMigrateReceive, args) < 0) {
 virReportError(VIR_ERR_OPERATION_FAILED, "%s",
_("Failed to create thread for receiving migration 
data"));
@@ -627,6 +629,7 @@ libxlDomainMigrationPrepareTunnel3(virConnectPtr dconn,
 goto done;
 
  error:
+libxlMigrationCookieFree(mig);
 VIR_FORCE_CLOSE(dataFD[1]);
 VIR_FORCE_CLOSE(dataFD[0]);
 virObjectUnref(args);
@@ -907,13 +910,15 @@ libxlMigrationStartTunnel(libxlDriverPrivatePtr driver,
   virDomainObjPtr vm,
   unsigned long flags,
   virStreamPtr st,
-  struct libxlTunnelControl *tc)
+  struct libxlTunnelControl **tnl)
 {
+struct libxlTunnelControl *tc = NULL;
 libxlTunnelMigrationThread *arg = NULL;
 int ret = -1;
 
 if (VIR_ALLOC(tc) < 0)
 goto out;
+*tnl = tc;
 
 tc->dataFD[0] = -1;
 tc->dataFD[1] = -1;
@@ -1045,7 +1050,7 @@ libxlDoMigrateP2P(libxlDriverPrivatePtr driver,
 
 VIR_DEBUG("Perform3 uri=%s", NULLSTR(uri_out));
 if (flags & VIR_MIGRATE_TUNNELLED)
-ret = libxlMigrationStartTunnel(driver, vm, flags, st, tc);
+ret = libxlMigrationStartTunnel(driver, vm, flags, st, );
 else
 ret = libxlDomainMigrationPerform(driver, vm, NULL, NULL,
   uri_out, NULL, flags);
-- 
2.1.4

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

Re: [libvirt] [PATCH v3 2/2] libxl: add tunnelled migration support

[Joao Martins]

On 02/16/2017 02:57 PM, John Ferlan wrote:
> On 02/16/2017 09:26 AM, Joao Martins wrote:
>> On 02/16/2017 11:47 AM, John Ferlan wrote:
>>> FYI: Couple of Coverity issues resulted from these patches.
>>>
>>>>  int
>>>> +libxlDomainMigrationPrepareTunnel3(virConnectPtr dconn,
>>>> +   virStreamPtr st,
>>>> +   virDomainDefPtr *def,
>>>> +   const char *cookiein,
>>>> +   int cookieinlen,
>>>> +   unsigned int flags)
>>>> +{
>>>> +libxlMigrationCookiePtr mig = NULL;
>>>> +libxlDriverPrivatePtr driver = dconn->privateData;
>>>> +virDomainObjPtr vm = NULL;
>>>> +libxlMigrationDstArgs *args = NULL;
>>>> +virThread thread;
>>>> +bool taint_hook = false;
>>>> +libxlDomainObjPrivatePtr priv = NULL;
>>>> +char *xmlout = NULL;
>>>> +int dataFD[2] = { -1, -1 };
>>>> +int ret = -1;
>>>> +
>>>> +if (libxlDomainMigrationPrepareAny(dconn, def, cookiein, cookieinlen,
>>>> +   , , _hook) < 0)
>>>
>>> Coverity notes that '@mig' will be leaked in this case when "if
>>> (!cookiein || !cookieinlen) {" is true in libxlMigrationEatCookie and
>>> failures from libxlDomainMigrationPrepareAny don't free it.
>>
>> /nods. This diff should do then? It covers both cases I think.
> 
> What about:
> 
> args->migcookie = mig;
> 
> 
> and then successful virThreadCreate(, false,
> libxlDoMigrateReceive, args) where 'args' is unref'd, but the cookie
> isn't free'd.
> 
> Certainly you wouldn't want to free the cookie and then let the thread
> use it!
\facepalm - you're right.

> So I think the libxlMigrationCookieFree needs to be done in the error:
> label and in the thread cleanup. Also after you assign @mig to
> migcookie, set 'mig = NULL';
Yeap, let me send that in a follow-up patch shortly.
The thread cleanup you mean libxlDoMigrateReceive right? There I think we could
simply move unref args to cleanup label (which would free the cookie). But
probably should go into a separate patch as it seems to be an issue to all
migration paths.

>> diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
>> index ba1ca5c..6a7d458 100644
>> --- a/src/libxl/libxl_migration.c
>> +++ b/src/libxl/libxl_migration.c
>> @@ -637,6 +637,7 @@ libxlDomainMigrationPrepareTunnel3(virConnectPtr dconn,
>>  }
>>
>>   done:
>> +libxlMigrationCookieFree(mig);
>>  if (vm)
>>  virObjectUnlock(vm);
>>
>>
>>
>>>> +goto error;
>>>> +
>>>> +if (!(vm = virDomainObjListAdd(driver->domains, *def,
>>>> +   driver->xmlopt,
>>>> +   VIR_DOMAIN_OBJ_LIST_ADD_LIVE |
>>>> +   VIR_DOMAIN_OBJ_LIST_ADD_CHECK_LIVE,
>>>> +   NULL)))
>>>> +goto error;
>>>> +
>>>> +*def = NULL;
>>>> +priv = vm->privateData;
>>>> +
>>>> +if (taint_hook) {
>>>> +/* Domain XML has been altered by a hook script. */
>>>> +priv->hookRun = true;
>>>> +}
>>>> +
>>>> +/*
>>>> + * The data flow of tunnel3 migration in the dest side:
>>>> + * stream -> pipe -> recvfd of libxlDomainStartRestore
>>>> + */
>>>> +if (pipe(dataFD) < 0)
>>>> +goto error;
>>>> +
>>>> +/* Stream data will be written to pipeIn */
>>>> +if (virFDStreamOpen(st, dataFD[1]) < 0)
>>>> +goto error;
>>>> +dataFD[1] = -1; /* 'st' owns the FD now & will close it */
>>>> +
>>>> +if (libxlMigrationDstArgsInitialize() < 0)
>>>> +goto error;
>>>> +
>>>> +if (!(args = virObjectNew(libxlMigrationDstArgsClass)))
>>>> +goto error;
>>>> +
>>>> +args->conn = dconn;
>>>> +args->vm = vm;
>>>> +args->flags = flags;
>>>> +args->migcookie = mig;
>>>> +/* Receive from pipeOut */
>>>> +args->recvfd = dataFD[0];
&

Re: [libvirt] [PATCH] news: document libxl tunnelled migration support

[Joao Martins]

On 02/16/2017 01:24 AM, Jim Fehlig wrote:
> On 02/15/2017 05:06 PM, Joao Martins wrote:
>> On 02/15/2017 11:41 PM, Jim Fehlig wrote:
>>> Joao Martins wrote:
>>>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>>>> ---
>>>>  docs/news.xml | 10 ++
>>>>  1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/docs/news.xml b/docs/news.xml
>>>> index b756a97..b0629b5 100644
>>>> --- a/docs/news.xml
>>>> +++ b/docs/news.xml
>>>> @@ -53,6 +53,16 @@
>>>>was virtio-net.
>>>>  
>>>>
>>>> +  
>>>> +
>>>> +  libxl: add tunnelled migration support
>>>> +
>>>> +
>>>> +  Add tunnelled migration to libxl driver, which is always 
>>>> capable of
>>>> +  strong encryption and doesn't require any extra network 
>>>> connection
>>>> +  other than what's required for remote access of libvirtd.
>>>> +
>>>> +  
>>>>  
>>>>  
>>>>
>>>
>>> Pushed, but only after realizing tunneled is misspelled :-(. No use 
>>> perpetuating
>>> the misspelling of tunneled, so I've pushed a trivial followup.
>>
>> Interesting, I didn't know that. Greping the whole repo for "tunnelled" and 
>> you
>> will find a *lot* of matches:
>>
>> $ git grep tunneled | wc -l
>> 10
>> $ git grep tunnelled | wc -l
>> 1242
> 
> So the incorrect spelling is used over 100x more than the correct one :-)

Hehe :D

>> Hmm, but the internets aren't really clear. Some hits say tunneled vs 
>> tunnelled
>> being both correct.
> 
> Heh, as a native speaker I'm not sure which spelling is correct, but seem to 
> recall a prior discussion on the list proclaiming 'tunneled'. If folks prefer 
> I 
> can revert the s/tunnelled/tunneled/ commit.

Sorry I may have mis-expressed myself before - didn't meant this being an issue.
I was just curious about the word because I made that same mistake throughout
the patches. Probably there's no need for revert with both appearing correct (as
folks are suggesting in followup messages)

Joao

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

Re: [libvirt] [PATCH v3 2/2] libxl: add tunnelled migration support

[Joao Martins]

On 02/16/2017 11:47 AM, John Ferlan wrote:
> FYI: Couple of Coverity issues resulted from these patches.
> 
>>  int
>> +libxlDomainMigrationPrepareTunnel3(virConnectPtr dconn,
>> +   virStreamPtr st,
>> +   virDomainDefPtr *def,
>> +   const char *cookiein,
>> +   int cookieinlen,
>> +   unsigned int flags)
>> +{
>> +libxlMigrationCookiePtr mig = NULL;
>> +libxlDriverPrivatePtr driver = dconn->privateData;
>> +virDomainObjPtr vm = NULL;
>> +libxlMigrationDstArgs *args = NULL;
>> +virThread thread;
>> +bool taint_hook = false;
>> +libxlDomainObjPrivatePtr priv = NULL;
>> +char *xmlout = NULL;
>> +int dataFD[2] = { -1, -1 };
>> +int ret = -1;
>> +
>> +if (libxlDomainMigrationPrepareAny(dconn, def, cookiein, cookieinlen,
>> +   , , _hook) < 0)
> 
> Coverity notes that '@mig' will be leaked in this case when "if
> (!cookiein || !cookieinlen) {" is true in libxlMigrationEatCookie and
> failures from libxlDomainMigrationPrepareAny don't free it.

/nods. This diff should do then? It covers both cases I think.

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index ba1ca5c..6a7d458 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -637,6 +637,7 @@ libxlDomainMigrationPrepareTunnel3(virConnectPtr dconn,
 }

  done:
+libxlMigrationCookieFree(mig);
 if (vm)
 virObjectUnlock(vm);



>> +goto error;
>> +
>> +if (!(vm = virDomainObjListAdd(driver->domains, *def,
>> +   driver->xmlopt,
>> +   VIR_DOMAIN_OBJ_LIST_ADD_LIVE |
>> +   VIR_DOMAIN_OBJ_LIST_ADD_CHECK_LIVE,
>> +   NULL)))
>> +goto error;
>> +
>> +*def = NULL;
>> +priv = vm->privateData;
>> +
>> +if (taint_hook) {
>> +/* Domain XML has been altered by a hook script. */
>> +priv->hookRun = true;
>> +}
>> +
>> +/*
>> + * The data flow of tunnel3 migration in the dest side:
>> + * stream -> pipe -> recvfd of libxlDomainStartRestore
>> + */
>> +if (pipe(dataFD) < 0)
>> +goto error;
>> +
>> +/* Stream data will be written to pipeIn */
>> +if (virFDStreamOpen(st, dataFD[1]) < 0)
>> +goto error;
>> +dataFD[1] = -1; /* 'st' owns the FD now & will close it */
>> +
>> +if (libxlMigrationDstArgsInitialize() < 0)
>> +goto error;
>> +
>> +if (!(args = virObjectNew(libxlMigrationDstArgsClass)))
>> +goto error;
>> +
>> +args->conn = dconn;
>> +args->vm = vm;
>> +args->flags = flags;
>> +args->migcookie = mig;
>> +/* Receive from pipeOut */
>> +args->recvfd = dataFD[0];
>> +args->nsocks = 0;
>> +if (virThreadCreate(, false, libxlDoMigrateReceive, args) < 0) {
>> +virReportError(VIR_ERR_OPERATION_FAILED, "%s",
>> +   _("Failed to create thread for receiving migration 
>> data"));
>> +goto error;
>> +}
>> +
>> +ret = 0;
>> +goto done;
>> +
>> + error:
>> +VIR_FORCE_CLOSE(dataFD[1]);
>> +VIR_FORCE_CLOSE(dataFD[0]);
>> +virObjectUnref(args);
>> +/* Remove virDomainObj from domain list */
>> +if (vm) {
>> +virDomainObjListRemove(driver->domains, vm);
>> +vm = NULL;
>> +}
>> +
>> + done:
>> +if (vm)
>> +virObjectUnlock(vm);
>> +
>> +return ret;
>> +}
> 
> [...]
> 
>> +
>> +static int
>> +libxlMigrationStartTunnel(libxlDriverPrivatePtr driver,
>> +  virDomainObjPtr vm,
>> +  unsigned long flags,
>> +  virStreamPtr st,
>> +  struct libxlTunnelControl *tc)
>> +{
>> +libxlTunnelMigrationThread *arg = NULL;
>> +int ret = -1;
>> +
>> +if (VIR_ALLOC(tc) < 0)
>> +goto out;
>> +
>> +tc->dataFD[0] = -1;
>> +tc->dataFD[1] = -1;
>> +if (pipe(tc->dataFD) < 0) {
>> +virReportError(errno, "%s", _("Unable to make pipes"));
> 
> Coverity notes that failures would cause a leak for @tc (I assume here
> and of course if virThreadCreate fails.  Perhaps the 'best' way to
> handle that would be to set tc = NULL after ThreadCreate success and
> just call libxlMigrationStopTunnel in "out:"...

But libxlMigrationStopTunnel is always called (hence should be freeing @tc),
whether libxlMigrationStartTunnel failed or not. How about this?

@@ -907,8 +908,9 @@ libxlMigrationStartTunnel(libxlDriverPrivatePtr driver,
   virDomainObjPtr vm,
   unsigned long flags,
   virStreamPtr st,
-  struct libxlTunnelControl *tc)
+  struct libxlTunnelControl **tnl)
 {
+struct 

Re: [libvirt] [PATCH] news: document libxl tunnelled migration support

[Joao Martins]

On 02/15/2017 11:41 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>> ---
>>  docs/news.xml | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/docs/news.xml b/docs/news.xml
>> index b756a97..b0629b5 100644
>> --- a/docs/news.xml
>> +++ b/docs/news.xml
>> @@ -53,6 +53,16 @@
>>was virtio-net.
>>  
>>
>> +  
>> +
>> +  libxl: add tunnelled migration support
>> +
>> +
>> +  Add tunnelled migration to libxl driver, which is always capable 
>> of
>> +  strong encryption and doesn't require any extra network connection
>> +  other than what's required for remote access of libvirtd.
>> +
>> +  
>>  
>>  
>>
> 
> Pushed, but only after realizing tunneled is misspelled :-(. No use 
> perpetuating
> the misspelling of tunneled, so I've pushed a trivial followup.

Interesting, I didn't know that. Greping the whole repo for "tunnelled" and you
will find a *lot* of matches:

$ git grep tunneled | wc -l
10
$ git grep tunnelled | wc -l
1242

Hmm, but the internets aren't really clear. Some hits say tunneled vs tunnelled
being both correct.

Joao

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

Re: [libvirt] [PATCH v3 0/2] libxl: tunnelled migration support

[Joao Martins]

On 02/15/2017 10:14 PM, Joao Martins wrote:
> On 02/15/2017 09:53 PM, Jim Fehlig wrote:
>> Joao Martins wrote:
>>> Hey!
>>>
>>> Presented herewith is take 4 from tunnelled migration addressing all 
>>> previous
>>> comments. No functional changes from v2, only revert to v1 on the top level
>>> migration functions and removing unnecessary usage of virReportError.
>>>
>>> Thanks,
>>> Joao
>>>
>>> Bob Liu (1):
>>>   libxl: add tunnelled migration support
>>>
>>> Joao Martins (1):
>>>   libxl: refactor libxlDomainMigrationPrepare
>>>
>>>  src/libxl/libxl_driver.c|  58 ++-
>>>  src/libxl/libxl_migration.c | 367 
>>> +---
>>>  src/libxl/libxl_migration.h |   9 ++
>>>  3 files changed, 381 insertions(+), 53 deletions(-)
>>>
>>
>> ACK series. I fixed up the indentation in 2/2 before pushing.
>>
>> This series is newsworthy. Can you post a followup adding an entry to
>> docs/news.xml describing this new feature? Thanks!
> Yeap, will do.
Just sent it over [0]. Maybe it's also worth adding news coverage to your  libxl
timer improvements, and the many maxmem related fixes :)

[0] https://www.redhat.com/archives/libvir-list/2017-February/msg00761.html

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

[libvirt] [PATCH] news: document libxl tunnelled migration support

[Joao Martins]

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 docs/news.xml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index b756a97..b0629b5 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -53,6 +53,16 @@
   was virtio-net.
 
   
+  
+
+  libxl: add tunnelled migration support
+
+
+  Add tunnelled migration to libxl driver, which is always capable of
+  strong encryption and doesn't require any extra network connection
+  other than what's required for remote access of libvirtd.
+
+  
 
 
   
-- 
2.1.4

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

Re: [libvirt] [PATCH v3 0/2] libxl: tunnelled migration support

[Joao Martins]

On 02/15/2017 09:53 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> Hey!
>>
>> Presented herewith is take 4 from tunnelled migration addressing all previous
>> comments. No functional changes from v2, only revert to v1 on the top level
>> migration functions and removing unnecessary usage of virReportError.
>>
>> Thanks,
>> Joao
>>
>> Bob Liu (1):
>>   libxl: add tunnelled migration support
>>
>> Joao Martins (1):
>>   libxl: refactor libxlDomainMigrationPrepare
>>
>>  src/libxl/libxl_driver.c|  58 ++-
>>  src/libxl/libxl_migration.c | 367 
>> +---
>>  src/libxl/libxl_migration.h |   9 ++
>>  3 files changed, 381 insertions(+), 53 deletions(-)
>>
> 
> ACK series. I fixed up the indentation in 2/2 before pushing.
> 
> This series is newsworthy. Can you post a followup adding an entry to
> docs/news.xml describing this new feature? Thanks!
Yeap, will do.

Thanks!
Joao

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

Re: [libvirt] [PATCH v3 2/2] libxl: add tunnelled migration support

[Joao Martins]

On 02/15/2017 11:17 AM, Joao Martins wrote:
> From: Bob Liu <bob@oracle.com>
> 
> Tunnelled migration doesn't require any extra network connections
> beside the libvirt daemon.  It's capable of strong encryption and the
> default option of openstack-nova.
> 
> This patch adds the tunnelled migration(Tunnel3params) support to
> libxl.  On the source side, the data flow is:
> 
>  * libxlDoMigrateSend() -> pipe libxlTunnel3MigrationFunc() polls pipe
>  * out and then write to dest stream.
> 
> While on the destination side:
>  * Stream -> pipe -> 'recvfd of libxlDomainStartRestore'
> 
> The usage is the same as p2p migration, execpt adding one extra
> '--tunnelled' to the libvirt p2p migration command.
> 
> Signed-off-by: Bob Liu <bob@oracle.com>
> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
> ---
> v3:
>  * virStream{Send,Finish} and VIR_ALLOC_N already report errors,
>  hence removing the virReportError calls from its error paths.
>  * Revert top-level migration APIs to initial v1 approach.
> v2:
>  ( Comments from Jim )
>  * Adjust common preparetunnel function reflecting v1 suggestions
>- Using common top-level Prepare function by adding is_tunnel variable
>- Using libxl_migration PrepareAny added in patch 1
>- virHook support in PrepareTunnel3
>  * Move virThreadPtr from libxlTunnelMigrationThread into libxlTunnelControl
>  * Rename function local variable from tmThreadPtr to arg
>  * Remove redundant assignment "tmThreadPtr = >tmThread;" always being not
>  null.
>  * Adjust debug message to "poll returned 0" as opposed to "poll got
>  timeout" as the latter might not always be the case.
> ---
>  src/libxl/libxl_driver.c|  58 +-
>  src/libxl/libxl_migration.c | 275 
> +---
>  src/libxl/libxl_migration.h |   9 ++
>  3 files changed, 325 insertions(+), 17 deletions(-)
> 
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index 74cb05a..e5b8f48 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -5934,6 +5934,61 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
>  }
>  
>  static int
> +libxlDomainMigratePrepareTunnel3Params(virConnectPtr dconn,
> +   virStreamPtr st,
> +   virTypedParameterPtr params,
> +   int nparams,
> +   const char *cookiein,
> +   int cookieinlen,
> +   char **cookieout ATTRIBUTE_UNUSED,
> +   int *cookieoutlen ATTRIBUTE_UNUSED,
> +   unsigned int flags)
> +{
> +libxlDriverPrivatePtr driver = dconn->privateData;
> +virDomainDefPtr def = NULL;
> +const char *dom_xml = NULL;
> +const char *dname = NULL;
> +const char *uri_in = NULL;
> +
> +#ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
> +virReportUnsupportedError();
> +return -1;
> +#endif
> +
> +virCheckFlags(LIBXL_MIGRATION_FLAGS, -1);
> +if (virTypedParamsValidate(params, nparams, LIBXL_MIGRATION_PARAMETERS) 
> < 0)
> +goto error;
> +
> +if (virTypedParamsGetString(params, nparams,
> +VIR_MIGRATE_PARAM_DEST_XML,
> +_xml) < 0 ||
> +virTypedParamsGetString(params, nparams,
> +VIR_MIGRATE_PARAM_DEST_NAME,
> +) < 0 ||
> +virTypedParamsGetString(params, nparams,
> +VIR_MIGRATE_PARAM_URI,
> +_in) < 0)
> +
> +goto error;
> +
> +if (!(def = libxlDomainMigrationPrepareDef(driver, dom_xml, dname)))
> +goto error;
> +
> +if (virDomainMigratePrepareTunnel3ParamsEnsureACL(dconn, def) < 0)
> +goto error;
> +
> +if (libxlDomainMigrationPrepareTunnel3(dconn, st, , cookiein,
> +   cookieinlen, flags) < 0)
> +goto error;
> +
> +return 0;
> +
> + error:
> +virDomainDefFree(def);
> +return -1;
> +}
> +
> +static int
>  libxlDomainMigratePrepare3Params(virConnectPtr dconn,
>   virTypedParameterPtr params,
>   int nparams,
> @@ -6033,7 +6088,7 @@ libxlDomainMigratePerform3Params(virDomainPtr dom,
>  if (virDomainMigratePerform3ParamsEnsureACL(dom->conn, vm->def) < 0)
>  goto cleanup;
>  
&

[libvirt] [PATCH v3 2/2] libxl: add tunnelled migration support

[Joao Martins]

From: Bob Liu <bob@oracle.com>

Tunnelled migration doesn't require any extra network connections
beside the libvirt daemon.  It's capable of strong encryption and the
default option of openstack-nova.

This patch adds the tunnelled migration(Tunnel3params) support to
libxl.  On the source side, the data flow is:

 * libxlDoMigrateSend() -> pipe libxlTunnel3MigrationFunc() polls pipe
 * out and then write to dest stream.

While on the destination side:
 * Stream -> pipe -> 'recvfd of libxlDomainStartRestore'

The usage is the same as p2p migration, execpt adding one extra
'--tunnelled' to the libvirt p2p migration command.

Signed-off-by: Bob Liu <bob@oracle.com>
Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
v3:
 * virStream{Send,Finish} and VIR_ALLOC_N already report errors,
 hence removing the virReportError calls from its error paths.
 * Revert top-level migration APIs to initial v1 approach.
v2:
 ( Comments from Jim )
 * Adjust common preparetunnel function reflecting v1 suggestions
   - Using common top-level Prepare function by adding is_tunnel variable
   - Using libxl_migration PrepareAny added in patch 1
   - virHook support in PrepareTunnel3
 * Move virThreadPtr from libxlTunnelMigrationThread into libxlTunnelControl
 * Rename function local variable from tmThreadPtr to arg
 * Remove redundant assignment "tmThreadPtr = >tmThread;" always being not
 null.
 * Adjust debug message to "poll returned 0" as opposed to "poll got
 timeout" as the latter might not always be the case.
---
 src/libxl/libxl_driver.c|  58 +-
 src/libxl/libxl_migration.c | 275 +---
 src/libxl/libxl_migration.h |   9 ++
 3 files changed, 325 insertions(+), 17 deletions(-)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 74cb05a..e5b8f48 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5934,6 +5934,61 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
 }
 
 static int
+libxlDomainMigratePrepareTunnel3Params(virConnectPtr dconn,
+   virStreamPtr st,
+   virTypedParameterPtr params,
+   int nparams,
+   const char *cookiein,
+   int cookieinlen,
+   char **cookieout ATTRIBUTE_UNUSED,
+   int *cookieoutlen ATTRIBUTE_UNUSED,
+   unsigned int flags)
+{
+libxlDriverPrivatePtr driver = dconn->privateData;
+virDomainDefPtr def = NULL;
+const char *dom_xml = NULL;
+const char *dname = NULL;
+const char *uri_in = NULL;
+
+#ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
+virReportUnsupportedError();
+return -1;
+#endif
+
+virCheckFlags(LIBXL_MIGRATION_FLAGS, -1);
+if (virTypedParamsValidate(params, nparams, LIBXL_MIGRATION_PARAMETERS) < 
0)
+goto error;
+
+if (virTypedParamsGetString(params, nparams,
+VIR_MIGRATE_PARAM_DEST_XML,
+_xml) < 0 ||
+virTypedParamsGetString(params, nparams,
+VIR_MIGRATE_PARAM_DEST_NAME,
+) < 0 ||
+virTypedParamsGetString(params, nparams,
+VIR_MIGRATE_PARAM_URI,
+_in) < 0)
+
+goto error;
+
+if (!(def = libxlDomainMigrationPrepareDef(driver, dom_xml, dname)))
+goto error;
+
+if (virDomainMigratePrepareTunnel3ParamsEnsureACL(dconn, def) < 0)
+goto error;
+
+if (libxlDomainMigrationPrepareTunnel3(dconn, st, , cookiein,
+   cookieinlen, flags) < 0)
+goto error;
+
+return 0;
+
+ error:
+virDomainDefFree(def);
+return -1;
+}
+
+static int
 libxlDomainMigratePrepare3Params(virConnectPtr dconn,
  virTypedParameterPtr params,
  int nparams,
@@ -6033,7 +6088,7 @@ libxlDomainMigratePerform3Params(virDomainPtr dom,
 if (virDomainMigratePerform3ParamsEnsureACL(dom->conn, vm->def) < 0)
 goto cleanup;
 
-if (flags & VIR_MIGRATE_PEER2PEER) {
+if ((flags & (VIR_MIGRATE_TUNNELLED | VIR_MIGRATE_PEER2PEER))) {
 if (libxlDomainMigrationPerformP2P(driver, vm, dom->conn, dom_xml,
dconnuri, uri, dname, flags) < 0)
 goto cleanup;
@@ -6518,6 +6573,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
 .nodeDeviceReset = libxlNodeDeviceReset, /* 1.2.3 */
 .domainMigrateBegin3Params = libxlDomainMigrateBegin3Params, /* 1.2.6 */
 .domainMigratePrepare3Params = libxlDomainMigratePrepare3Params, /* 1.2.6 
*/
+.domainMigratePrepa

[libvirt] [PATCH v3 0/2] libxl: tunnelled migration support

[Joao Martins]

Hey!

Presented herewith is take 4 from tunnelled migration addressing all previous
comments. No functional changes from v2, only revert to v1 on the top level
migration functions and removing unnecessary usage of virReportError.

Thanks,
Joao

Bob Liu (1):
  libxl: add tunnelled migration support

Joao Martins (1):
  libxl: refactor libxlDomainMigrationPrepare

 src/libxl/libxl_driver.c|  58 ++-
 src/libxl/libxl_migration.c | 367 +---
 src/libxl/libxl_migration.h |   9 ++
 3 files changed, 381 insertions(+), 53 deletions(-)

-- 
2.1.4

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

[libvirt] [PATCH v3 1/2] libxl: refactor libxlDomainMigrationPrepare

[Joao Martins]

The newly introduced function libxlDomainMigrationPrepareAny
will be shared between P2P and tunnelled variations.

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 src/libxl/libxl_migration.c | 92 +++--
 1 file changed, 56 insertions(+), 36 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index a471d2a..7beabd2 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -483,41 +483,26 @@ libxlDomainMigrationPrepareDef(libxlDriverPrivatePtr 
driver,
 return def;
 }
 
-int
-libxlDomainMigrationPrepare(virConnectPtr dconn,
-virDomainDefPtr *def,
-const char *uri_in,
-char **uri_out,
-const char *cookiein,
-int cookieinlen,
-unsigned int flags)
+static int
+libxlDomainMigrationPrepareAny(virConnectPtr dconn,
+   virDomainDefPtr *def,
+   const char *cookiein,
+   int cookieinlen,
+   libxlMigrationCookiePtr *mig,
+   char **xmlout,
+   bool *taint_hook)
 {
 libxlDriverPrivatePtr driver = dconn->privateData;
 libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
-libxlMigrationCookiePtr mig = NULL;
-virDomainObjPtr vm = NULL;
-char *hostname = NULL;
-char *xmlout = NULL;
-unsigned short port;
-char portstr[100];
-virURIPtr uri = NULL;
-virNetSocketPtr *socks = NULL;
-size_t nsocks = 0;
-int nsocks_listen = 0;
-libxlMigrationDstArgs *args = NULL;
-bool taint_hook = false;
-libxlDomainObjPrivatePtr priv = NULL;
-size_t i;
-int ret = -1;
 
-if (libxlMigrationEatCookie(cookiein, cookieinlen, ) < 0)
-goto error;
+if (libxlMigrationEatCookie(cookiein, cookieinlen, mig) < 0)
+return -1;
 
-if (mig->xenMigStreamVer > LIBXL_SAVE_VERSION) {
+if ((*mig)->xenMigStreamVer > LIBXL_SAVE_VERSION) {
 virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("Xen migration stream version '%d' is not supported 
on this host"),
-   mig->xenMigStreamVer);
-goto error;
+   (*mig)->xenMigStreamVer);
+return -1;
 }
 
 /* Let migration hook filter domain XML */
@@ -528,29 +513,29 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 if (!(xml = virDomainDefFormat(*def, cfg->caps,
VIR_DOMAIN_XML_SECURE |
VIR_DOMAIN_XML_MIGRATABLE)))
-goto error;
+return -1;
 
 hookret = virHookCall(VIR_HOOK_DRIVER_LIBXL, (*def)->name,
   VIR_HOOK_LIBXL_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN,
-  NULL, xml, );
+  NULL, xml, xmlout);
 VIR_FREE(xml);
 
 if (hookret < 0) {
-goto error;
+return -1;
 } else if (hookret == 0) {
-if (virStringIsEmpty(xmlout)) {
+if (virStringIsEmpty(*xmlout)) {
 VIR_DEBUG("Migrate hook filter returned nothing; using the"
   " original XML");
 } else {
 virDomainDefPtr newdef;
 
-VIR_DEBUG("Using hook-filtered domain XML: %s", xmlout);
-newdef = virDomainDefParseString(xmlout, cfg->caps, 
driver->xmlopt,
+VIR_DEBUG("Using hook-filtered domain XML: %s", *xmlout);
+newdef = virDomainDefParseString(*xmlout, cfg->caps, 
driver->xmlopt,
  NULL,
  VIR_DOMAIN_DEF_PARSE_INACTIVE 
|
  
VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE);
 if (!newdef)
-goto error;
+return -1;
 
 /* TODO At some stage we will want to have some check of what 
the user
  * did in the hook. */
@@ -560,17 +545,52 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 /* We should taint the domain here. However, @vm and therefore
  * privateData too are still NULL, so just notice the fact and
  * taint it later. */
-taint_hook = true;
+*taint_hook = true;
 }
 }
 }
 
+return 0;
+}
+
+int
+libxlDomainMigrationPrepare(virConnectPtr dconn,
+virDomainDefPtr *def,
+const char *uri_in,
+char **uri_out,
+const char 

Re: [libvirt] [PATCH v2 3/3] libxl: add tunnelled migration support

[Joao Martins]

On 02/14/2017 03:34 AM, Jim Fehlig wrote:
> On 02/07/2017 05:35 PM, Joao Martins wrote:
>> From: Bob Liu <bob@oracle.com>
>>
>> Tunnelled migration doesn't require any extra network connections beside
>> the libvirt daemon.  It's capable of strong encryption and the default
>> option of openstack-nova.
>>
>> This patch adds the tunnelled migration(Tunnel3params) support to libxl.
>> On the source side, the data flow is:
>>
>>  * libxlDoMigrateSend() -> pipe libxlTunnel3MigrationFunc() polls pipe
>>  * out and then write to dest stream.
>>
>> While on the destination side:
>>  * Stream -> pipe -> 'recvfd of libxlDomainStartRestore'
>>
>> The usage is the same as p2p migration, execpt adding one extra
>> '--tunnelled' to the libvirt p2p migration command.
>>
>> Signed-off-by: Bob Liu <bob@oracle.com>
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>> ---
>> v2 (comments from Jim):
>>  * Adjust common preparetunnel function reflecting v1 suggestions
>>- Using common top-level Prepare function by adding is_tunnel variable
>>- Using libxl_migration PrepareAny added in patch 1
>>- virHook support in PrepareTunnel3
>>  * Move virThreadPtr from libxlTunnelMigrationThread into libxlTunnelControl
>>  * Rename function local variable from tmThreadPtr to arg
>>  * Remove redundant assignment "tmThreadPtr = >tmThread;" always being 
>> not
>>  null.
>> ---
>>  src/libxl/libxl_driver.c|  49 ++--
>>  src/libxl/libxl_migration.c | 280 
>> +---
>>  src/libxl/libxl_migration.h |   9 ++
>>  3 files changed, 313 insertions(+), 25 deletions(-)
>>
>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>> index 7bc8adf..b34f120 100644
>> --- a/src/libxl/libxl_driver.c
>> +++ b/src/libxl/libxl_driver.c
>> @@ -5938,14 +5938,14 @@ libxlDomainMigratePrepareCommon(virConnectPtr dconn,
>>  char **cookieout ATTRIBUTE_UNUSED,
>>  int *cookieoutlen ATTRIBUTE_UNUSED,
>>  unsigned int flags,
>> -void *data)
>> +void *data,
>> +bool is_tunnel)
>>  {
>>  libxlDriverPrivatePtr driver = dconn->privateData;
>>  virDomainDefPtr def = NULL;
>>  const char *dom_xml = NULL;
>>  const char *dname = NULL;
>>  const char *uri_in = NULL;
>> -char **uri_out = data;
>>
>>  #ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
>>  virReportUnsupportedError();
>> @@ -5971,12 +5971,25 @@ libxlDomainMigratePrepareCommon(virConnectPtr dconn,
>>  if (!(def = libxlDomainMigrationPrepareDef(driver, dom_xml, dname)))
>>  goto error;
>>
>> -if (virDomainMigratePrepare3ParamsEnsureACL(dconn, def) < 0)
>> -goto error;
>> +if (is_tunnel) {
>> +virStreamPtr st = data;
>>
>> -if (libxlDomainMigrationPrepare(dconn, , uri_in, uri_out,
>> -cookiein, cookieinlen, flags) < 0)
>> -goto error;
>> +if (virDomainMigratePrepareTunnel3ParamsEnsureACL(dconn, def) < 0)
>> +goto error;
>> +
>> +if (libxlDomainMigrationPrepareTunnel3(dconn, st, , cookiein,
>> +   cookieinlen, flags) < 0)
>> +goto error;
>> +} else {
>> +char **uri_out = data;
>> +
>> +if (virDomainMigratePrepare3ParamsEnsureACL(dconn, def) < 0)
>> +goto error;
>> +
>> +if (libxlDomainMigrationPrepare(dconn, , uri_in, uri_out,
>> +cookiein, cookieinlen, flags) < 0)
>> +goto error;
>> +}
> 
> Same comment here about the ACL checks and 'make check. With both patches 
> applied
> 
> ./libxl/libxl_driver.c:5981 Mismatch check 
> 'virDomainMigratePrepareTunnel3ParamsEnsureACL' for function 
> 'libxlDomainMigratePrepareCommon'
> ./libxl/libxl_driver.c:5990 Mismatch check 
> 'virDomainMigratePrepare3ParamsEnsureACL' for function 
> 'libxlDomainMigratePrepareCommon'
Yeap, see my comment in the previous patch.

>>  return 0;
>>
>> @@ -5999,7 +6012,24 @@ libxlDomainMigratePrepare3Params(virConnectPtr dconn,
>>  return libxlDomainMigratePrepareCommon(dconn, params, nparams,
>>  

Re: [libvirt] [PATCH v2 2/3] libxl: streamline top-level migrate functions

[Joao Martins]

On 02/14/2017 03:13 AM, Jim Fehlig wrote:
> On 02/07/2017 05:35 PM, Joao Martins wrote:
>> This allows us to reuse a single function for both tunnelled and
>> non-tunnelled variants.
>>
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>> ---
>> New in v2
>> ---
>>  src/libxl/libxl_driver.c | 36 +++-
>>  1 file changed, 27 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>> index 3a69720..7bc8adf 100644
>> --- a/src/libxl/libxl_driver.c
>> +++ b/src/libxl/libxl_driver.c
>> @@ -5930,21 +5930,22 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
>>  }
>>
>>  static int
>> -libxlDomainMigratePrepare3Params(virConnectPtr dconn,
>> - virTypedParameterPtr params,
>> - int nparams,
>> - const char *cookiein,
>> - int cookieinlen,
>> - char **cookieout ATTRIBUTE_UNUSED,
>> - int *cookieoutlen ATTRIBUTE_UNUSED,
>> - char **uri_out,
>> - unsigned int flags)
>> +libxlDomainMigratePrepareCommon(virConnectPtr dconn,
>> +virTypedParameterPtr params,
>> +int nparams,
>> +const char *cookiein,
>> +int cookieinlen,
>> +char **cookieout ATTRIBUTE_UNUSED,
>> +int *cookieoutlen ATTRIBUTE_UNUSED,
>> +unsigned int flags,
>> +void *data)
>>  {
>>  libxlDriverPrivatePtr driver = dconn->privateData;
>>  virDomainDefPtr def = NULL;
>>  const char *dom_xml = NULL;
>>  const char *dname = NULL;
>>  const char *uri_in = NULL;
>> +char **uri_out = data;
>>
>>  #ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
>>  virReportUnsupportedError();
>> @@ -5985,6 +5986,23 @@ libxlDomainMigratePrepare3Params(virConnectPtr dconn,
>>  }
>>
>>  static int
>> +libxlDomainMigratePrepare3Params(virConnectPtr dconn,
>> + virTypedParameterPtr params,
>> + int nparams,
>> + const char *cookiein,
>> + int cookieinlen,
>> + char **cookieout ATTRIBUTE_UNUSED,
>> + int *cookieoutlen ATTRIBUTE_UNUSED,
>> + char **uri_out,
>> + unsigned int flags)
>> +{
>> +return libxlDomainMigratePrepareCommon(dconn, params, nparams,
>> +   cookiein, cookieinlen,
>> +   cookieout, cookieoutlen,
>> +   flags, uri_out);
>> +}
> 
> It appears the ACL check must be done in libxlDomainMigratePrepare3Params to 
> satisfy 'make check'
> 
> ./libxl/libxl_driver.c:5978 Mismatch check 
> 'virDomainMigratePrepare3ParamsEnsureACL' for function 
> 'libxlDomainMigratePrepareCommon'

Sorry, I naively ran solely the syntax checks when rebasing this series.

The ACL checks require dconn and def, and consequently the call to fetch def:

def = libxlDomainMigrationPrepareDef(driver, dom_xml, dname);

Requires dom_xml and dname being fetched from params.

Given all these dependencies having this common function for both prepare
functions doesn't seem to be doing much, as the top-level functions would end up
being very similar after these dependencies. Which makes me wonder if we should
dropped this (i.e. remove this PrepareCommon function) instead and go like
initial v1 (same comment would be applicable for the PrepareTunnel3Params in
patch 3). What do you think?

Joao

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

Re: [libvirt] [PATCH V2 2/2] libxl: fix dom0 maximum memory setting

[Joao Martins]

On 02/09/2017 04:58 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> On 02/08/2017 10:24 PM, Jim Fehlig wrote:
>>> When the libxl driver is initialized, it creates a virDomainDef
>>> object for dom0 and adds it to the list of domains. Total memory
>>> for dom0 was being set from the max_memkb field of libxl_dominfo
>>> struct retrieved from libxl, but this field can be set to
>>> LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
>>> explicitly set by the user.
>>>
>>> This patch adds some simple parsing of the Xen commandline,
>>> looking for a dom0_mem parameter that also specifies a 'max' value.
>>> If not specified, dom0 maximum memory is effectively all physical
>>> host memory.
>>>
>>> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
>>
>> Argh, sorry. Failed to mention one (non-blocking) observation in the patch 
>> about
>> the parsing of "dom0_mem". Regardless,
>>
>> Acked-by: Joao Martins <joao.m.mart...@oracle.com>
>>
>>> ---
>>>
>>> V2: Check return value of libxl_get_physinfo and
>>> libxlDriverGetDom0MaxmemConf.
>>>
>>>  src/libxl/libxl_conf.c   | 77 
>>> 
>>>  src/libxl/libxl_conf.h   |  4 +++
>>>  src/libxl/libxl_driver.c |  5 +++-
>>>  3 files changed, 85 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index 28b05e1..7e30c7d 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -34,6 +34,7 @@
>>>  #include "internal.h"
>>>  #include "virlog.h"
>>>  #include "virerror.h"
>>> +#include "c-ctype.h"
>>>  #include "datatypes.h"
>>>  #include "virconf.h"
>>>  #include "virfile.h"
>>> @@ -1533,6 +1534,82 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr 
>>> cfg,
>>>  
>>>  }
>>>  
>>> +/*
>>> + * dom0's maximum memory can be controled by the user with the 'dom0_mem' 
>>> Xen
>>> + * command line parameter. E.g. to set dom0's initial memory to 4G and max
>>> + * memory to 8G: dom0_mem=4G,max:8G
>>> + *
>>> + * If not constrained by the user, dom0 can effectively use all host 
>>> memory.
>>> + * This function returns the configured maximum memory for dom0 in 
>>> kilobytes,
>>> + * either the user-specified value or total physical memory as a default.
>>> + */
>>> +int
>>> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg,
>>> + unsigned long long *maxmem)
>>> +{
>>> +char **cmd_tokens = NULL;
>>> +char **mem_tokens = NULL;
>>> +size_t i;
>>> +size_t j;
>>> +libxl_physinfo physinfo;
>>> +int ret = -1;
>>> +
>>> +if (cfg->verInfo->commandline == NULL ||
>>> +!(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
>>> +goto physmem;
>>> +
>>> +for (i = 0; cmd_tokens[i] != NULL; i++) {
>>> +if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
>>> +continue;
>>> +
>>> +if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
>>> +break;
>>> +for (j = 0; mem_tokens[j] != NULL; j++) {
>>> +if (STRPREFIX(mem_tokens[j], "max:")) {
>>> +char *p = mem_tokens[j] + 4;
>>> +unsigned long long multiplier = 1;
>> Hmm, perhaps worth a comment here (or in the command at the top of the 
>> function)
>> because if the parameter doesn't have a suffix it defaults to kilobytes (as 
>> per
>> Xen command line docs).
> 
> I've added another sentence to the comment at the top of the function.
> 
>>
>>> +
>>> +while (c_isdigit(*p))
>>> +p++;
>>> +if (virStrToLong_ull(mem_tokens[j] + 4, , 10, maxmem) < 
>>> 0)
>>> +break;
>>> +if (*p) {
>>> +switch (*p) {
>>> +case 'm':
>>> +case 'M':
>>> +multiplier = 1024;
>>> +break;
>>> +case 'g':
>>>

Re: [libvirt] [PATCH V2 2/2] libxl: fix dom0 maximum memory setting

[Joao Martins]

On 02/09/2017 12:39 PM, Joao Martins wrote:
> On 02/08/2017 10:24 PM, Jim Fehlig wrote:
>> When the libxl driver is initialized, it creates a virDomainDef
>> object for dom0 and adds it to the list of domains. Total memory
>> for dom0 was being set from the max_memkb field of libxl_dominfo
>> struct retrieved from libxl, but this field can be set to
>> LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
>> explicitly set by the user.
>>
>> This patch adds some simple parsing of the Xen commandline,
>> looking for a dom0_mem parameter that also specifies a 'max' value.
>> If not specified, dom0 maximum memory is effectively all physical
>> host memory.
>>
>> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
> 
> Argh, sorry. Failed to mention one (non-blocking) observation in the patch 
> about
> the parsing of "dom0_mem". Regardless,
> 
> Acked-by: Joao Martins <joao.m.mart...@oracle.com>
> 
>> ---
>>
>> V2: Check return value of libxl_get_physinfo and
>> libxlDriverGetDom0MaxmemConf.
>>
>>  src/libxl/libxl_conf.c   | 77 
>> 
>>  src/libxl/libxl_conf.h   |  4 +++
>>  src/libxl/libxl_driver.c |  5 +++-
>>  3 files changed, 85 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>> index 28b05e1..7e30c7d 100644
>> --- a/src/libxl/libxl_conf.c
>> +++ b/src/libxl/libxl_conf.c
>> @@ -34,6 +34,7 @@
>>  #include "internal.h"
>>  #include "virlog.h"
>>  #include "virerror.h"
>> +#include "c-ctype.h"
>>  #include "datatypes.h"
>>  #include "virconf.h"
>>  #include "virfile.h"
>> @@ -1533,6 +1534,82 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr 
>> cfg,
>>  
>>  }
>>  
>> +/*
>> + * dom0's maximum memory can be controled by the user with the 'dom0_mem' 
>> Xen
>> + * command line parameter. E.g. to set dom0's initial memory to 4G and max
>> + * memory to 8G: dom0_mem=4G,max:8G
>> + *
>> + * If not constrained by the user, dom0 can effectively use all host memory.
>> + * This function returns the configured maximum memory for dom0 in 
>> kilobytes,
>> + * either the user-specified value or total physical memory as a default.
>> + */
>> +int
>> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg,
>> + unsigned long long *maxmem)
>> +{
>> +char **cmd_tokens = NULL;
>> +char **mem_tokens = NULL;
>> +size_t i;
>> +size_t j;
>> +libxl_physinfo physinfo;
>> +int ret = -1;
>> +
>> +if (cfg->verInfo->commandline == NULL ||
>> +!(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
>> +goto physmem;
>> +
>> +for (i = 0; cmd_tokens[i] != NULL; i++) {
>> +if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
>> +continue;
>> +
>> +if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
>> +break;
>> +for (j = 0; mem_tokens[j] != NULL; j++) {
>> +if (STRPREFIX(mem_tokens[j], "max:")) {
>> +char *p = mem_tokens[j] + 4;
>> +unsigned long long multiplier = 1;
> Hmm, perhaps worth a comment here (or in the command at the top of the 
> function)
> because if the parameter doesn't have a suffix it defaults to kilobytes (as 
> per
> Xen command line docs).
> 
>> +
>> +while (c_isdigit(*p))
>> +p++;
>> +if (virStrToLong_ull(mem_tokens[j] + 4, , 10, maxmem) < 0)
>> +break;
>> +if (*p) {
>> +switch (*p) {
>> +case 'm':
>> +case 'M':
>> +multiplier = 1024;
>> +break;
>> +case 'g':
>> +case 'G':
>> +multiplier = 1024 * 1024;
>> +break;
>> +}
>> +}
>> +*maxmem = *maxmem * multiplier;
>> +ret = 0;
>> +goto cleanup;
> This seems to match xen's parsing of the parameter that is for "max=4GG" or
> "max=4GM" the latter suffix will be ignored (thus considering 4G only). I was
> looking at the Xen's code of dom0_mem parsing and it's documentation - and
> noticed that we don't support Terabytes in the parsing above. Though this is
> only since Xen 4.5.
To avoid ambiguity here I meant the snippet above doesn't Terabytes, but its
correspondent support on Xen is only since 4.5.

Joao

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

Re: [libvirt] [PATCH V2 2/2] libxl: fix dom0 maximum memory setting

[Joao Martins]

On 02/08/2017 10:24 PM, Jim Fehlig wrote:
> When the libxl driver is initialized, it creates a virDomainDef
> object for dom0 and adds it to the list of domains. Total memory
> for dom0 was being set from the max_memkb field of libxl_dominfo
> struct retrieved from libxl, but this field can be set to
> LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
> explicitly set by the user.
> 
> This patch adds some simple parsing of the Xen commandline,
> looking for a dom0_mem parameter that also specifies a 'max' value.
> If not specified, dom0 maximum memory is effectively all physical
> host memory.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>

Argh, sorry. Failed to mention one (non-blocking) observation in the patch about
the parsing of "dom0_mem". Regardless,

Acked-by: Joao Martins <joao.m.mart...@oracle.com>

> ---
> 
> V2: Check return value of libxl_get_physinfo and
> libxlDriverGetDom0MaxmemConf.
> 
>  src/libxl/libxl_conf.c   | 77 
> 
>  src/libxl/libxl_conf.h   |  4 +++
>  src/libxl/libxl_driver.c |  5 +++-
>  3 files changed, 85 insertions(+), 1 deletion(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index 28b05e1..7e30c7d 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -34,6 +34,7 @@
>  #include "internal.h"
>  #include "virlog.h"
>  #include "virerror.h"
> +#include "c-ctype.h"
>  #include "datatypes.h"
>  #include "virconf.h"
>  #include "virfile.h"
> @@ -1533,6 +1534,82 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
>  
>  }
>  
> +/*
> + * dom0's maximum memory can be controled by the user with the 'dom0_mem' Xen
> + * command line parameter. E.g. to set dom0's initial memory to 4G and max
> + * memory to 8G: dom0_mem=4G,max:8G
> + *
> + * If not constrained by the user, dom0 can effectively use all host memory.
> + * This function returns the configured maximum memory for dom0 in kilobytes,
> + * either the user-specified value or total physical memory as a default.
> + */
> +int
> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg,
> + unsigned long long *maxmem)
> +{
> +char **cmd_tokens = NULL;
> +char **mem_tokens = NULL;
> +size_t i;
> +size_t j;
> +libxl_physinfo physinfo;
> +int ret = -1;
> +
> +if (cfg->verInfo->commandline == NULL ||
> +!(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
> +goto physmem;
> +
> +for (i = 0; cmd_tokens[i] != NULL; i++) {
> +if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
> +continue;
> +
> +if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
> +break;
> +for (j = 0; mem_tokens[j] != NULL; j++) {
> +if (STRPREFIX(mem_tokens[j], "max:")) {
> +char *p = mem_tokens[j] + 4;
> +unsigned long long multiplier = 1;
Hmm, perhaps worth a comment here (or in the command at the top of the function)
because if the parameter doesn't have a suffix it defaults to kilobytes (as per
Xen command line docs).

> +
> +while (c_isdigit(*p))
> +p++;
> +if (virStrToLong_ull(mem_tokens[j] + 4, , 10, maxmem) < 0)
> +break;
> +if (*p) {
> +switch (*p) {
> +case 'm':
> +case 'M':
> +multiplier = 1024;
> +break;
> +case 'g':
> +case 'G':
> +multiplier = 1024 * 1024;
> +break;
> +}
> +}
> +*maxmem = *maxmem * multiplier;
> +ret = 0;
> +goto cleanup;
This seems to match xen's parsing of the parameter that is for "max=4GG" or
"max=4GM" the latter suffix will be ignored (thus considering 4G only). I was
looking at the Xen's code of dom0_mem parsing and it's documentation - and
noticed that we don't support Terabytes in the parsing above. Though this is
only since Xen 4.5.

> +}
> +}
> +}
> +
> + physmem:
> +/* No 'max' specified in dom0_mem, so dom0 can use all physical memory */
> +libxl_physinfo_init();
> +if (libxl_get_physinfo(cfg->ctx, )) {
> +VIR_WARN("libxl_get_physinfo failed");
> +goto cleanup;
> +}
> +*maxmem = (physinfo.total_pages * cfg->verInfo-&g

Re: [libvirt] [PATCH V2 1/2] libxl: fix reporting of maximum memory

[Joao Martins]

On 02/08/2017 10:24 PM, Jim Fehlig wrote:
> The libxl driver reports different values of maximum memory depending
> on state of a domain. If inactive, maximum memory value is reported
> correctly. When active, maximum memory is derived from max_pages value
> returned by the XEN_SYSCTL_getdomaininfolist sysctl operation. But
> max_pages can be changed by toolstacks and does not necessarily
> represent the maximum memory a domain can use during its active
> lifetime.
> 
> A better location for determining a domain's maximum memory is the
> /local/domain//memory/static-max node in xenstore. This value
> is set from the libxl_domain_build_info.max_memkb field when creating
> the domain. Currently it cannot be changed nor can its value be
> exceeded by a balloon operation. From libvirt's perspective, always
> reporting maximum memory with virDomainDefGetMemoryTotal() will produce
> the same results as reading the static-max node in xenstore.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>

Acked-by: Joao Martins <joao.m.mart...@oracle.com>

> ---
>  src/libxl/libxl_driver.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index 38ad91e..040b986 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -1640,10 +1640,10 @@ libxlDomainGetInfo(virDomainPtr dom, virDomainInfoPtr 
> info)
>  if (virDomainGetInfoEnsureACL(dom->conn, vm->def) < 0)
>  goto cleanup;
>  
> +info->maxMem = virDomainDefGetMemoryTotal(vm->def);
>  if (!virDomainObjIsActive(vm)) {
>  info->cpuTime = 0;
>  info->memory = vm->def->mem.cur_balloon;
> -info->maxMem = virDomainDefGetMemoryTotal(vm->def);
>  } else {
>  libxl_dominfo_init(_info);
>  
> @@ -1655,7 +1655,6 @@ libxlDomainGetInfo(virDomainPtr dom, virDomainInfoPtr 
> info)
>  }
>  info->cpuTime = d_info.cpu_time;
>  info->memory = d_info.current_memkb;
> -info->maxMem = d_info.max_memkb;
>  
>  libxl_dominfo_dispose(_info);
>  }
> @@ -5174,7 +5173,7 @@ libxlDomainMemoryStats(virDomainPtr dom,
>  goto endjob;
>  }
>  mem = d_info.current_memkb;
> -maxmem = d_info.max_memkb;
> +maxmem = virDomainDefGetMemoryTotal(vm->def);
>  
>  LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON, mem);
>  LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_AVAILABLE, maxmem);
> 

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

Re: [libvirt] [PATCH 2/2] libxl: fix dom0 maximum memory setting

[Joao Martins]

On 02/08/2017 04:06 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> On 02/02/2017 10:31 PM, Jim Fehlig wrote:
>>> When the libxl driver is initialized, it creates a virDomainDef
>>> object for dom0 and adds it to the list of domains. Total memory
>>> for dom0 was being set from the max_memkb field of libxl_dominfo
>>> struct retrieved from libxl, but this field can be set to
>>> LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
>>> explicitly set by the user.
>>>
>>> This patch adds some simple parsing of the Xen commandline,
>>> looking for a dom0_mem parameter that also specifies a 'max' value.
>>> If not specified, dom0 maximum memory is effectively all physical
>>> host memory.
>>>
>>> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
>>> ---
>>>  src/libxl/libxl_conf.c   | 75 
>>> 
>>>  src/libxl/libxl_conf.h   |  3 ++
>>>  src/libxl/libxl_driver.c |  2 +-
>>>  3 files changed, 79 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index b5186f2..bfe0e92 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -34,6 +34,7 @@
>>>  #include "internal.h"
>>>  #include "virlog.h"
>>>  #include "virerror.h"
>>> +#include "c-ctype.h"
>>>  #include "datatypes.h"
>>>  #include "virconf.h"
>>>  #include "virfile.h"
>>> @@ -1530,6 +1531,80 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr 
>>> cfg,
>>>  
>>>  }
>>>  
>>> +/*
>>> + * dom0's maximum memory can be controled by the user with the 'dom0_mem' 
>>> Xen
>>> + * command line parameter. E.g. to set dom0's initial memory to 4G and max
>>> + * memory to 8G: dom0_mem=4G,max:8G
>>> + *
>>> + * If not constrained by the user, dom0 can effectively use all host 
>>> memory.
>>> + * This function returns the configured maximum memory for dom0 in 
>>> kilobytes,
>>> + * either the user-specified value or total physical memory as a default.
>>> + */
>>> +unsigned long long
>>> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg)
>>> +{
>>> +char **cmd_tokens = NULL;
>>> +char **mem_tokens = NULL;
>>> +size_t i;
>>> +size_t j;
>>> +unsigned long long ret;
>>> +libxl_physinfo physinfo;
>>> +
>>> +if (cfg->verInfo->commandline == NULL ||
>>> +!(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
>>> +goto physmem;
>>> +
>>> +for (i = 0; cmd_tokens[i] != NULL; i++) {
>>> +if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
>>> +continue;
>>> +
>>> +if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
>>> +break;
>>> +for (j = 0; mem_tokens[j] != NULL; j++) {
>>> +if (STRPREFIX(mem_tokens[j], "max:")) {
>>> +char *p = mem_tokens[j] + 4;
>>> +unsigned long long multiplier = 1;
>>> +
>>> +while (c_isdigit(*p))
>>> +p++;
>>> +if (virStrToLong_ull(mem_tokens[j] + 4, , 10, ) < 0)
>>> +break;
>>> +if (*p) {
>>> +switch (*p) {
>>> +case 'k':
>>> +case 'K':
>>> +multiplier = 1024;
>>> +break;
>>> +case 'm':
>>> +case 'M':
>>> +multiplier = 1024 * 1024;
>>> +break;
>>> +case 'g':
>>> +case 'G':
>>> +multiplier = 1024 * 1024 * 1024;
>>> +break;
>>> +}
>>> +}
>>> +ret = (ret * multiplier) / 1024;
>>> +goto cleanup;
>>> +}
>>> +}
>>> +}
>>> +
>>> + physmem:
>>> +/* No 'max' specified in dom0_mem, so dom0 can use all physical memory 
>>> */
>>> +libxl_physinfo_init();
>>&

Re: [libvirt] [PATCH 2/2] libxl: use init and dispose functions with libxl_physinfo

[Joao Martins]

On 02/08/2017 04:17 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> On 02/02/2017 10:39 PM, Jim Fehlig wrote:
>>> The typical pattern when calling libxl functions that populate a
>>> structure is
>>>
>>>   libxl_foo foo;
>>>   libxl_foo_init();
>>>   libxl_get_foo(ctx, );
>>>   ...
>>>   libxl_foo_dispose();
>>>
>>> Fix several instances of libxl_physinfo missing the init and
>>> dispose calls.
>> Indeed,
>>
>>> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
>>
>> Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>
>>
>> See also one comment/nit below, perhaps one libxl_physinfo_init could be 
>> moved
>> slightly up..
>>
>>> [...]
>>
>>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>>> index 3a69720..8951bef 100644
>>> --- a/src/libxl/libxl_driver.c
>>> +++ b/src/libxl/libxl_driver.c
>>> @@ -4286,6 +4286,7 @@ libxlNodeGetFreeMemory(virConnectPtr conn)
>>>  if (virNodeGetFreeMemoryEnsureACL(conn) < 0)
>>>  goto cleanup;
>>>  
>>> +libxl_physinfo_init(_info);
>>
>> .. namely here? That is before virNodeGetFreeMemoryEnsureACL.
> 
> Nice catch. Moved as suggested in my local branch.
> 
> Any other comments on this small series? Would be nice to get these bug fixes
> committed :-).
> 
Nope, looks all good to me:

Acked-by: Joao Martins <joao.m.mart...@oracle.com>

> Regards,
> Jim
> 
>>
>> Not that it matters much, as init/dispose in this case just zeroes out 
>> phy_info
>> region. But just perhaps consistency as you would end disposing an non
>> initialized object.
>>
>>>  if (libxl_get_physinfo(cfg->ctx, _info)) {
>>>  virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
>>> _("libxl_get_physinfo_info failed"));
>>> @@ -4295,6 +4296,7 @@ libxlNodeGetFreeMemory(virConnectPtr conn)
>>>  ret = phy_info.free_pages * cfg->verInfo->pagesize;
>>>  
>>>   cleanup:
>>> +libxl_physinfo_dispose(_info);
>>>  virObjectUnref(cfg);
>>>  return ret;
>>>  }
>>>
> 

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

[libvirt] [PATCH RFC 1/4] qemu_agent: move agent into util

[Joao Martins]

As it could be shared with libxl which now allows channels to
be created. Also changed filename to match others in the same
directory namely to virqemuagent.{h,c}

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 po/POTFILES.in   |2 +-
 src/Makefile.am  |2 +-
 src/libvirt_private.syms |   21 +
 src/qemu/qemu_agent.c| 2248 --
 src/qemu/qemu_agent.h|  123 ---
 src/qemu/qemu_domain.h   |2 +-
 src/qemu/qemu_driver.c   |2 +-
 src/util/virqemuagent.c  | 2248 ++
 src/util/virqemuagent.h  |  123 +++
 tests/qemuagenttest.c|2 +-
 tests/qemumonitortestutils.c |2 +-
 tests/qemumonitortestutils.h |2 +-
 12 files changed, 2399 insertions(+), 2378 deletions(-)
 delete mode 100644 src/qemu/qemu_agent.c
 delete mode 100644 src/qemu/qemu_agent.h
 create mode 100644 src/util/virqemuagent.c
 create mode 100644 src/util/virqemuagent.h

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 365ea66..ebb247b 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -122,7 +122,6 @@ src/openvz/openvz_conf.c
 src/openvz/openvz_driver.c
 src/openvz/openvz_util.c
 src/phyp/phyp_driver.c
-src/qemu/qemu_agent.c
 src/qemu/qemu_alias.c
 src/qemu/qemu_capabilities.c
 src/qemu/qemu_cgroup.c
@@ -239,6 +238,7 @@ src/util/virpolkit.c
 src/util/virportallocator.c
 src/util/virprocess.c
 src/util/virqemu.c
+src/util/virqemuagent.c
 src/util/virrandom.c
 src/util/virrotatingfile.c
 src/util/virscsi.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 2f32d41..62c8733 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -161,6 +161,7 @@ UTIL_SOURCES =  
\
util/virprobe.h \
util/virprocess.c util/virprocess.h \
util/virqemu.c util/virqemu.h   \
+   util/virqemuagent.c util/virqemuagent.h \
util/virrandom.h util/virrandom.c   \
util/virrotatingfile.h util/virrotatingfile.c   \
util/virscsi.c util/virscsi.h   \
@@ -815,7 +816,6 @@ VBOX_DRIVER_EXTRA_DIST =
\
vbox/vbox_XPCOMCGlue.c vbox/vbox_XPCOMCGlue.h
 
 QEMU_DRIVER_SOURCES =  \
-   qemu/qemu_agent.c qemu/qemu_agent.h \
qemu/qemu_alias.c qemu/qemu_alias.h \
qemu/qemu_blockjob.c qemu/qemu_blockjob.h   \
qemu/qemu_capabilities.c qemu/qemu_capabilities.h   \
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index d556c7d..a5a1313 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2306,6 +2306,27 @@ virQEMUBuildLuksOpts;
 virQEMUBuildObjectCommandlineFromJSON;
 
 
+# util/virqemuagent.h
+qemuAgentArbitraryCommand;
+qemuAgentClose;
+qemuAgentFSFreeze;
+qemuAgentFSThaw;
+qemuAgentFSTrim;
+qemuAgentGetFSInfo;
+qemuAgentGetInterfaces;
+qemuAgentGetTime;
+qemuAgentGetVCPUs;
+qemuAgentNotifyClose;
+qemuAgentNotifyEvent;
+qemuAgentOpen;
+qemuAgentSetVCPUs;
+qemuAgentSetUserPassword;
+qemuAgentSetTime;
+qemuAgentShutdown;
+qemuAgentSuspend;
+qemuAgentUpdateCPUInfo;
+
+
 # util/virrandom.h
 virRandom;
 virRandomBits;
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
deleted file mode 100644
index 46cad53..000
--- a/src/qemu/qemu_agent.c
+++ /dev/null
@@ -1,2248 +0,0 @@
-/*
- * qemu_agent.c: interaction with QEMU guest agent
- *
- * Copyright (C) 2006-2014 Red Hat, Inc.
- * Copyright (C) 2006 Daniel P. Berrange
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library.  If not, see
- * <http://www.gnu.org/licenses/>.
- *
- * Author: Daniel P. Berrange <berra...@redhat.com>
- */
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "qemu_agent.h"
-#include "viralloc.h"
-#include "virlog.h"
-#include "virerror.h"
-#include "virjson.h"
-#include "virfile.h"
-#include "virprocess.h"
-#include "virtime.h"
-#include "virobject.h"
-#include "virstring.h"
-#include "base64.h&qu

[libvirt] [PATCH RFC 2/4] qemu_agent: ignore requests echoed back by guest

[Joao Martins]

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 src/util/virqemuagent.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/util/virqemuagent.c b/src/util/virqemuagent.c
index caabae0..ffb3489 100644
--- a/src/util/virqemuagent.c
+++ b/src/util/virqemuagent.c
@@ -333,7 +333,8 @@ qemuAgentIOProcessLine(qemuAgentPtr mon,
 goto cleanup;
 }
 
-if (virJSONValueObjectHasKey(obj, "QMP") == 1) {
+if (virJSONValueObjectHasKey(obj, "QMP") == 1 ||
+virJSONValueObjectHasKey(obj, "execute") == 1) {
 ret = 0;
 } else if (virJSONValueObjectHasKey(obj, "event") == 1) {
 ret = qemuAgentIOProcessEvent(mon, obj);
-- 
2.1.4

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

[libvirt] [PATCH RFC 0/4] libxl: qemu agent support

[Joao Martins]

Hey!

Back when channels were introduced in libxl (in answer to Michal[0]) I
suggested the idea of integrating qemu guest agent (which currently lives
qemu driver).

This series is an attempt at pulling qemu agent from qemu driver into util in
using it in libxl in subsequent patches. What do folks think of the idea? Note
that this is still all very RFC because 1) there's a lot of code we could
potentially share between qemu and libxl with respect to finding guest agent
config and keeping some of its state (see patch 3); 2) also we need to ignore
"execute" messages to be able to query the agent and see it's returned data
(patch 2). Which despite the commit not being incorrect I am not sure yet why
we need it yet.

As PoC I only implemented domainQemuAgentCommand/domainInterfaceAddresses, but
there's a lot more driver APIs we can potentially introduce after this. Tracing
all driver APIs that might require a guest agent:

* domainFSThaw, domainFSFreeze, domainFSTrim, domainGetFSInfo
* domainSetUserPassword
* domainGetTime, domainSetTime
* domainShutdown (with VIR_DOMAIN_SHUTDOWN_GUEST_AGENT)
* domainReboot (with VIR_DOMAIN_REBOOT_GUEST_AGENT)
* domainGetGuestVcpus
* domainSetGuestVcpus
* domainSetVcpusFlags (with VIR_DOMAIN_VCPU_GUEST)
* domainGetVcpusFlags (with VIR_DOMAIN_VCPU_GUEST)

Comments/Feedback is appreciated :)

Cheers,
Joao

[0] https://www.spinics.net/linux/fedora/libvir/msg136685.html

Joao Martins (4):
  qemu_agent: move agent into util
  qemu_agent: ignore requests echoed back by guest
  libxl: implement qemu-agent-command
  libxl: domainInterfaceAddresses agent support

 po/POTFILES.in   |2 +-
 src/Makefile.am  |2 +-
 src/libvirt_private.syms |   21 +
 src/libxl/libxl_domain.c |  239 -
 src/libxl/libxl_domain.h |   16 +
 src/libxl/libxl_driver.c |   69 ++
 src/qemu/qemu_agent.c| 2248 -
 src/qemu/qemu_agent.h|  123 ---
 src/qemu/qemu_domain.h   |2 +-
 src/qemu/qemu_driver.c   |2 +-
 src/util/virqemuagent.c  | 2249 ++
 src/util/virqemuagent.h  |  123 +++
 tests/qemuagenttest.c|2 +-
 tests/qemumonitortestutils.c |2 +-
 tests/qemumonitortestutils.h |2 +-
 15 files changed, 2723 insertions(+), 2379 deletions(-)
 delete mode 100644 src/qemu/qemu_agent.c
 delete mode 100644 src/qemu/qemu_agent.h
 create mode 100644 src/util/virqemuagent.c
 create mode 100644 src/util/virqemuagent.h

-- 
2.1.4

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

[libvirt] [PATCH RFC 4/4] libxl: domainInterfaceAddresses agent support

[Joao Martins]

Allow querying of guest interface address through agent
through command `virsh domifaddr test --source agent`

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 src/libxl/libxl_driver.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index cf5e702..8f8fbec 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -6261,6 +6261,8 @@ libxlDomainInterfaceAddresses(virDomainPtr dom,
   unsigned int source,
   unsigned int flags)
 {
+libxlDriverPrivatePtr driver = dom->conn->privateData;
+libxlDomainObjPrivatePtr priv;
 virDomainObjPtr vm = NULL;
 int ret = -1;
 
@@ -6282,6 +6284,22 @@ libxlDomainInterfaceAddresses(virDomainPtr dom,
 case VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_LEASE:
 ret = libxlGetDHCPInterfaces(dom, vm, ifaces);
 break;
+case VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_AGENT:
+priv = vm->privateData;
+if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_QUERY) < 0)
+goto cleanup;
+
+if (!libxlDomainAgentAvailable(vm, true))
+goto endjob;
+
+libxlDomainObjEnterAgent(vm);
+ret = qemuAgentGetInterfaces(priv->agent, ifaces);
+libxlDomainObjExitAgent(vm);
+
+endjob:
+libxlDomainObjEndJob(driver, vm);
+
+break;
 
 default:
 virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED,
-- 
2.1.4

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

[libvirt] [PATCH RFC 3/4] libxl: implement qemu-agent-command

[Joao Martins]

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 src/libxl/libxl_domain.c | 239 ++-
 src/libxl/libxl_domain.h |  16 
 src/libxl/libxl_driver.c |  51 ++
 3 files changed, 305 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index ed73cd2..6bdd0ec 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -782,6 +782,12 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
 }
 }
 
+if (priv->agent) {
+qemuAgentClose(priv->agent);
+priv->agent = NULL;
+priv->agentError = false;
+}
+
 if ((vm->def->nnets)) {
 size_t i;
 
@@ -940,6 +946,228 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config 
*d_config)
 return -1;
 }
 
+/*
+ * This is a callback registered with a qemuAgentPtr instance,
+ * and to be invoked when the agent console hits an end of file
+ * condition, or error, thus indicating VM shutdown should be
+ * performed
+ */
+static void
+libxlHandleAgentEOF(qemuAgentPtr agent,
+  virDomainObjPtr vm)
+{
+libxlDomainObjPrivatePtr priv;
+
+VIR_DEBUG("Received EOF from agent on %p '%s'", vm, vm->def->name);
+
+virObjectLock(vm);
+
+priv = vm->privateData;
+
+if (!priv->agent) {
+VIR_DEBUG("Agent freed already");
+goto unlock;
+}
+
+qemuAgentClose(agent);
+priv->agent = NULL;
+
+ unlock:
+virObjectUnlock(vm);
+return;
+}
+
+
+/*
+ * This is invoked when there is some kind of error
+ * parsing data to/from the agent. The VM can continue
+ * to run, but no further agent commands will be
+ * allowed
+ */
+static void
+libxlHandleAgentError(qemuAgentPtr agent ATTRIBUTE_UNUSED,
+virDomainObjPtr vm)
+{
+libxlDomainObjPrivatePtr priv;
+
+VIR_DEBUG("Received error from agent on %p '%s'", vm, vm->def->name);
+
+virObjectLock(vm);
+
+priv = vm->privateData;
+
+priv->agentError = true;
+
+virObjectUnlock(vm);
+}
+
+static void libxlHandleAgentDestroy(qemuAgentPtr agent,
+  virDomainObjPtr vm)
+{
+VIR_DEBUG("Received destroy agent=%p vm=%p", agent, vm);
+
+virObjectUnref(vm);
+}
+
+static qemuAgentCallbacks agentCallbacks = {
+.destroy = libxlHandleAgentDestroy,
+.eofNotify = libxlHandleAgentEOF,
+.errorNotify = libxlHandleAgentError,
+};
+
+static virDomainChrDefPtr
+libxlFindAgentConfig(virDomainDefPtr def)
+{
+size_t i;
+
+for (i = 0; i < def->nchannels; i++) {
+virDomainChrDefPtr channel = def->channels[i];
+
+if (channel->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN)
+continue;
+
+if (STREQ_NULLABLE(channel->target.name, "org.qemu.guest_agent.0"))
+return channel;
+}
+
+return NULL;
+}
+
+bool
+libxlDomainAgentAvailable(virDomainObjPtr vm, bool reportError)
+{
+libxlDomainObjPrivatePtr priv = vm->privateData;
+
+if (virDomainObjGetState(vm, NULL) != VIR_DOMAIN_RUNNING) {
+if (reportError) {
+virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+   _("domain is not running"));
+}
+return false;
+}
+if (priv->agentError) {
+if (reportError) {
+virReportError(VIR_ERR_AGENT_UNRESPONSIVE, "%s",
+   _("QEMU guest agent is not "
+ "available due to an error"));
+}
+return false;
+}
+if (!priv->agent) {
+if (libxlFindAgentConfig(vm->def)) {
+if (reportError) {
+virReportError(VIR_ERR_AGENT_UNRESPONSIVE, "%s",
+   _("QEMU guest agent is not connected"));
+}
+return false;
+} else {
+if (reportError) {
+virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
+   _("QEMU guest agent is not configured"));
+}
+return false;
+}
+}
+return true;
+}
+
+static int
+libxlConnectAgent(virDomainObjPtr vm)
+{
+virDomainChrDefPtr config = libxlFindAgentConfig(vm->def);
+libxlDomainObjPrivatePtr priv = vm->privateData;
+qemuAgentPtr agent = NULL;
+int ret = -1;
+
+if (!config)
+return 0;
+
+if (priv->agent)
+return 0;
+
+/* Hold an extra reference because we can't allow 'vm' to be
+ * deleted while the agent is active */
+virObjectRef(vm);
+
+ignore_value(virTimeMillisNow(>agentStart));
+virObjectUnlock(vm);
+
+agent = qemuAgentOpen(vm, config->source, );
+
+virObjectLock(vm);
+priv->agentStart = 0;
+
+if (agent == NULL)
+virObjec

Re: [libvirt] [PATCH 2/2] libxl: fix dom0 maximum memory setting

[Joao Martins]

On 02/02/2017 10:31 PM, Jim Fehlig wrote:
> When the libxl driver is initialized, it creates a virDomainDef
> object for dom0 and adds it to the list of domains. Total memory
> for dom0 was being set from the max_memkb field of libxl_dominfo
> struct retrieved from libxl, but this field can be set to
> LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
> explicitly set by the user.
> 
> This patch adds some simple parsing of the Xen commandline,
> looking for a dom0_mem parameter that also specifies a 'max' value.
> If not specified, dom0 maximum memory is effectively all physical
> host memory.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  src/libxl/libxl_conf.c   | 75 
> 
>  src/libxl/libxl_conf.h   |  3 ++
>  src/libxl/libxl_driver.c |  2 +-
>  3 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index b5186f2..bfe0e92 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -34,6 +34,7 @@
>  #include "internal.h"
>  #include "virlog.h"
>  #include "virerror.h"
> +#include "c-ctype.h"
>  #include "datatypes.h"
>  #include "virconf.h"
>  #include "virfile.h"
> @@ -1530,6 +1531,80 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
>  
>  }
>  
> +/*
> + * dom0's maximum memory can be controled by the user with the 'dom0_mem' Xen
> + * command line parameter. E.g. to set dom0's initial memory to 4G and max
> + * memory to 8G: dom0_mem=4G,max:8G
> + *
> + * If not constrained by the user, dom0 can effectively use all host memory.
> + * This function returns the configured maximum memory for dom0 in kilobytes,
> + * either the user-specified value or total physical memory as a default.
> + */
> +unsigned long long
> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg)
> +{
> +char **cmd_tokens = NULL;
> +char **mem_tokens = NULL;
> +size_t i;
> +size_t j;
> +unsigned long long ret;
> +libxl_physinfo physinfo;
> +
> +if (cfg->verInfo->commandline == NULL ||
> +!(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
> +goto physmem;
> +
> +for (i = 0; cmd_tokens[i] != NULL; i++) {
> +if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
> +continue;
> +
> +if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
> +break;
> +for (j = 0; mem_tokens[j] != NULL; j++) {
> +if (STRPREFIX(mem_tokens[j], "max:")) {
> +char *p = mem_tokens[j] + 4;
> +unsigned long long multiplier = 1;
> +
> +while (c_isdigit(*p))
> +p++;
> +if (virStrToLong_ull(mem_tokens[j] + 4, , 10, ) < 0)
> +break;
> +if (*p) {
> +switch (*p) {
> +case 'k':
> +case 'K':
> +multiplier = 1024;
> +break;
> +case 'm':
> +case 'M':
> +multiplier = 1024 * 1024;
> +break;
> +case 'g':
> +case 'G':
> +multiplier = 1024 * 1024 * 1024;
> +break;
> +}
> +}
> +ret = (ret * multiplier) / 1024;
> +goto cleanup;
> +}
> +}
> +}
> +
> + physmem:
> +/* No 'max' specified in dom0_mem, so dom0 can use all physical memory */
> +libxl_physinfo_init();
> +libxl_get_physinfo(cfg->ctx, );
Despite being an unlikely event, libxl_get_physinfo can fail here - I think you
need to check the return value here.

> +ret = (physinfo.total_pages * cfg->verInfo->pagesize) / 1024;
> +libxl_physinfo_dispose();
> +
> + cleanup:
> +virStringListFree(cmd_tokens);
> +virStringListFree(mem_tokens);
> +return ret;
> +}
> +
> +
>  #ifdef LIBXL_HAVE_DEVICE_CHANNEL
>  static int
>  libxlPrepareChannel(virDomainChrDefPtr channel,
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 69d7885..c4ddbfe 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -173,6 +173,9 @@ libxlDriverNodeGetInfo(libxlDriverPrivatePtr driver,
>  int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
>const char *filename);
>  
> +unsigned long long
> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg);
> +
>  int
>  libxlMakeDisk(virDomainDiskDefPtr l_dev, libxl_device_disk *x_dev);
>  int
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index 921cc93..e54b3b7 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -615,7 +615,7 @@ libxlAddDom0(libxlDriverPrivatePtr driver)
>  if (virDomainDefSetVcpus(vm->def, d_info.vcpu_online) < 0)
>  goto cleanup;
>  vm->def->mem.cur_balloon = 

Re: [libvirt] [PATCH 2/2] libxl: use init and dispose functions with libxl_physinfo

[Joao Martins]

On 02/02/2017 10:39 PM, Jim Fehlig wrote:
> The typical pattern when calling libxl functions that populate a
> structure is
> 
>   libxl_foo foo;
>   libxl_foo_init();
>   libxl_get_foo(ctx, );
>   ...
>   libxl_foo_dispose();
> 
> Fix several instances of libxl_physinfo missing the init and
> dispose calls.
Indeed,

> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>

Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>

See also one comment/nit below, perhaps one libxl_physinfo_init could be moved
slightly up..

> [...]

> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index 3a69720..8951bef 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -4286,6 +4286,7 @@ libxlNodeGetFreeMemory(virConnectPtr conn)
>  if (virNodeGetFreeMemoryEnsureACL(conn) < 0)
>  goto cleanup;
>  
> +libxl_physinfo_init(_info);

.. namely here? That is before virNodeGetFreeMemoryEnsureACL.

Not that it matters much, as init/dispose in this case just zeroes out phy_info
region. But just perhaps consistency as you would end disposing an non
initialized object.

>  if (libxl_get_physinfo(cfg->ctx, _info)) {
>  virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> _("libxl_get_physinfo_info failed"));
> @@ -4295,6 +4296,7 @@ libxlNodeGetFreeMemory(virConnectPtr conn)
>  ret = phy_info.free_pages * cfg->verInfo->pagesize;
>  
>   cleanup:
> +libxl_physinfo_dispose(_info);
>  virObjectUnref(cfg);
>  return ret;
>  }
> 

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

Re: [libvirt] [PATCH 1/2] libxl: honor autoballoon setting in libxl.conf

[Joao Martins]

On 02/02/2017 10:39 PM, Jim Fehlig wrote:
> libxlGetAutoballoonConf is supposed to honor user-specified
> autoballoon setting in libxl.conf. As written, the user-specified
> setting could be overwritten by the subsequent logic to check
> dom0_mem parameter. If user-specified setting is present and
> correct, accept it. Only fallback to checking Xen dom0_mem
> command line parameter if user-specfied setting is not present.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
Nice catch!

Reviewed-by: Joao Martins <joao.m.mart...@oracle.com>

> ---
>  src/libxl/libxl_conf.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index b5186f2..ee1e639 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -1355,8 +1355,11 @@ libxlGetAutoballoonConf(libxlDriverConfigPtr cfg,
>  regex_t regex;
>  int res;
>  
> -if (virConfGetValueBool(conf, "autoballoon", >autoballoon) < 0)
> +res = virConfGetValueBool(conf, "autoballoon", >autoballoon);
> +if (res < 0)
>  return -1;
> +else if (res == 1)
> +return 0;
>  
>  if ((res = regcomp(,
>"(^| )dom0_mem=((|min:|max:)[0-9]+[bBkKmMgG]?,?)+($| 
> )",
> 

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

[libvirt] [PATCH] xenconfig: fix xml conversion convert with no graphics

[Joao Martins]

If no graphics element is in XML xenFormatXLSpice will access
graphics without checking it has one in the first place, leading to a
segmentation fault.

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 src/xenconfig/xen_xl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
index 2c9174e..74f68b3 100644
--- a/src/xenconfig/xen_xl.c
+++ b/src/xenconfig/xen_xl.c
@@ -1168,7 +1168,7 @@ xenFormatXLSpice(virConfPtr conf, virDomainDefPtr def)
 virDomainGraphicsListenDefPtr glisten;
 virDomainGraphicsDefPtr graphics;
 
-if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
+if (def->os.type == VIR_DOMAIN_OSTYPE_HVM && def->graphics) {
 graphics = def->graphics[0];
 
 if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) {
-- 
2.1.4

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

Re: [libvirt] [PATCH v2 0/3] libxl: tunnelled migration support

[Joao Martins]

On 02/08/2017 12:35 AM, Joao Martins wrote:
> Hey!
> 
> Presented herewith is take 2 from tunnelled migration addressing all previous
> comments. Changelog in individual patches (patch 1 and 2 are small 
> refactorings
> suggested in v1) Despite being functional changes mostly I had a quick round 
> of
> testing too.
Argh, My apologies. It seems I chained reply all patches by mistake - I can
respin if folks prefer.

Joao

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

[libvirt] [PATCH v2 3/3] libxl: add tunnelled migration support

[Joao Martins]

From: Bob Liu <bob@oracle.com>

Tunnelled migration doesn't require any extra network connections beside
the libvirt daemon.  It's capable of strong encryption and the default
option of openstack-nova.

This patch adds the tunnelled migration(Tunnel3params) support to libxl.
On the source side, the data flow is:

 * libxlDoMigrateSend() -> pipe libxlTunnel3MigrationFunc() polls pipe
 * out and then write to dest stream.

While on the destination side:
 * Stream -> pipe -> 'recvfd of libxlDomainStartRestore'

The usage is the same as p2p migration, execpt adding one extra
'--tunnelled' to the libvirt p2p migration command.

Signed-off-by: Bob Liu <bob@oracle.com>
Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
v2 (comments from Jim):
 * Adjust common preparetunnel function reflecting v1 suggestions
   - Using common top-level Prepare function by adding is_tunnel variable
   - Using libxl_migration PrepareAny added in patch 1
   - virHook support in PrepareTunnel3
 * Move virThreadPtr from libxlTunnelMigrationThread into libxlTunnelControl
 * Rename function local variable from tmThreadPtr to arg
 * Remove redundant assignment "tmThreadPtr = >tmThread;" always being not
 null.
---
 src/libxl/libxl_driver.c|  49 ++--
 src/libxl/libxl_migration.c | 280 +---
 src/libxl/libxl_migration.h |   9 ++
 3 files changed, 313 insertions(+), 25 deletions(-)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 7bc8adf..b34f120 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5938,14 +5938,14 @@ libxlDomainMigratePrepareCommon(virConnectPtr dconn,
 char **cookieout ATTRIBUTE_UNUSED,
 int *cookieoutlen ATTRIBUTE_UNUSED,
 unsigned int flags,
-void *data)
+void *data,
+bool is_tunnel)
 {
 libxlDriverPrivatePtr driver = dconn->privateData;
 virDomainDefPtr def = NULL;
 const char *dom_xml = NULL;
 const char *dname = NULL;
 const char *uri_in = NULL;
-char **uri_out = data;
 
 #ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
 virReportUnsupportedError();
@@ -5971,12 +5971,25 @@ libxlDomainMigratePrepareCommon(virConnectPtr dconn,
 if (!(def = libxlDomainMigrationPrepareDef(driver, dom_xml, dname)))
 goto error;
 
-if (virDomainMigratePrepare3ParamsEnsureACL(dconn, def) < 0)
-goto error;
+if (is_tunnel) {
+virStreamPtr st = data;
 
-if (libxlDomainMigrationPrepare(dconn, , uri_in, uri_out,
-cookiein, cookieinlen, flags) < 0)
-goto error;
+if (virDomainMigratePrepareTunnel3ParamsEnsureACL(dconn, def) < 0)
+goto error;
+
+if (libxlDomainMigrationPrepareTunnel3(dconn, st, , cookiein,
+   cookieinlen, flags) < 0)
+goto error;
+} else {
+char **uri_out = data;
+
+if (virDomainMigratePrepare3ParamsEnsureACL(dconn, def) < 0)
+goto error;
+
+if (libxlDomainMigrationPrepare(dconn, , uri_in, uri_out,
+cookiein, cookieinlen, flags) < 0)
+goto error;
+}
 
 return 0;
 
@@ -5999,7 +6012,24 @@ libxlDomainMigratePrepare3Params(virConnectPtr dconn,
 return libxlDomainMigratePrepareCommon(dconn, params, nparams,
cookiein, cookieinlen,
cookieout, cookieoutlen,
-   flags, uri_out);
+   flags, uri_out, false);
+}
+
+static int
+libxlDomainMigratePrepareTunnel3Params(virConnectPtr dconn,
+   virStreamPtr st,
+   virTypedParameterPtr params,
+   int nparams,
+   const char *cookiein,
+   int cookieinlen,
+   char **cookieout ATTRIBUTE_UNUSED,
+   int *cookieoutlen ATTRIBUTE_UNUSED,
+   unsigned int flags)
+{
+return libxlDomainMigratePrepareCommon(dconn, params, nparams,
+   cookiein, cookieinlen,
+   cookieout, cookieoutlen,
+   flags, st, true);
 }
 
 static int
@@ -6047,7 +6077,7 @@ libxlDomainMigratePerform3Params(virDomainPtr dom,
 if (virDomainMigratePerform3ParamsEnsureACL(dom->conn, vm->def) < 0)
 goto cleanup;
 
-if (flags & VIR_MIGRATE_PEER2PEER) {
+if ((flags & (VIR_MIGRATE_TUNNELLED | VIR_MIGR

[libvirt] [PATCH v2 1/3] libxl: refactor libxlDomainMigrationPrepare

[Joao Martins]

The newly introduced function libxlDomainMigrationPrepareAny
will be shared between P2P and tunnelled variations.

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
New in v2
---
 src/libxl/libxl_migration.c | 92 +++--
 1 file changed, 56 insertions(+), 36 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index a471d2a..7beabd2 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -483,41 +483,26 @@ libxlDomainMigrationPrepareDef(libxlDriverPrivatePtr 
driver,
 return def;
 }
 
-int
-libxlDomainMigrationPrepare(virConnectPtr dconn,
-virDomainDefPtr *def,
-const char *uri_in,
-char **uri_out,
-const char *cookiein,
-int cookieinlen,
-unsigned int flags)
+static int
+libxlDomainMigrationPrepareAny(virConnectPtr dconn,
+   virDomainDefPtr *def,
+   const char *cookiein,
+   int cookieinlen,
+   libxlMigrationCookiePtr *mig,
+   char **xmlout,
+   bool *taint_hook)
 {
 libxlDriverPrivatePtr driver = dconn->privateData;
 libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
-libxlMigrationCookiePtr mig = NULL;
-virDomainObjPtr vm = NULL;
-char *hostname = NULL;
-char *xmlout = NULL;
-unsigned short port;
-char portstr[100];
-virURIPtr uri = NULL;
-virNetSocketPtr *socks = NULL;
-size_t nsocks = 0;
-int nsocks_listen = 0;
-libxlMigrationDstArgs *args = NULL;
-bool taint_hook = false;
-libxlDomainObjPrivatePtr priv = NULL;
-size_t i;
-int ret = -1;
 
-if (libxlMigrationEatCookie(cookiein, cookieinlen, ) < 0)
-goto error;
+if (libxlMigrationEatCookie(cookiein, cookieinlen, mig) < 0)
+return -1;
 
-if (mig->xenMigStreamVer > LIBXL_SAVE_VERSION) {
+if ((*mig)->xenMigStreamVer > LIBXL_SAVE_VERSION) {
 virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("Xen migration stream version '%d' is not supported 
on this host"),
-   mig->xenMigStreamVer);
-goto error;
+   (*mig)->xenMigStreamVer);
+return -1;
 }
 
 /* Let migration hook filter domain XML */
@@ -528,29 +513,29 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 if (!(xml = virDomainDefFormat(*def, cfg->caps,
VIR_DOMAIN_XML_SECURE |
VIR_DOMAIN_XML_MIGRATABLE)))
-goto error;
+return -1;
 
 hookret = virHookCall(VIR_HOOK_DRIVER_LIBXL, (*def)->name,
   VIR_HOOK_LIBXL_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN,
-  NULL, xml, );
+  NULL, xml, xmlout);
 VIR_FREE(xml);
 
 if (hookret < 0) {
-goto error;
+return -1;
 } else if (hookret == 0) {
-if (virStringIsEmpty(xmlout)) {
+if (virStringIsEmpty(*xmlout)) {
 VIR_DEBUG("Migrate hook filter returned nothing; using the"
   " original XML");
 } else {
 virDomainDefPtr newdef;
 
-VIR_DEBUG("Using hook-filtered domain XML: %s", xmlout);
-newdef = virDomainDefParseString(xmlout, cfg->caps, 
driver->xmlopt,
+VIR_DEBUG("Using hook-filtered domain XML: %s", *xmlout);
+newdef = virDomainDefParseString(*xmlout, cfg->caps, 
driver->xmlopt,
  NULL,
  VIR_DOMAIN_DEF_PARSE_INACTIVE 
|
  
VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE);
 if (!newdef)
-goto error;
+return -1;
 
 /* TODO At some stage we will want to have some check of what 
the user
  * did in the hook. */
@@ -560,17 +545,52 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 /* We should taint the domain here. However, @vm and therefore
  * privateData too are still NULL, so just notice the fact and
  * taint it later. */
-taint_hook = true;
+*taint_hook = true;
 }
 }
 }
 
+return 0;
+}
+
+int
+libxlDomainMigrationPrepare(virConnectPtr dconn,
+virDomainDefPtr *def,
+const char *uri_in,
+char **uri_out,
+const

[libvirt] [PATCH v2 2/3] libxl: streamline top-level migrate functions

[Joao Martins]

This allows us to reuse a single function for both tunnelled and
non-tunnelled variants.

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
New in v2
---
 src/libxl/libxl_driver.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 3a69720..7bc8adf 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5930,21 +5930,22 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
 }
 
 static int
-libxlDomainMigratePrepare3Params(virConnectPtr dconn,
- virTypedParameterPtr params,
- int nparams,
- const char *cookiein,
- int cookieinlen,
- char **cookieout ATTRIBUTE_UNUSED,
- int *cookieoutlen ATTRIBUTE_UNUSED,
- char **uri_out,
- unsigned int flags)
+libxlDomainMigratePrepareCommon(virConnectPtr dconn,
+virTypedParameterPtr params,
+int nparams,
+const char *cookiein,
+int cookieinlen,
+char **cookieout ATTRIBUTE_UNUSED,
+int *cookieoutlen ATTRIBUTE_UNUSED,
+unsigned int flags,
+void *data)
 {
 libxlDriverPrivatePtr driver = dconn->privateData;
 virDomainDefPtr def = NULL;
 const char *dom_xml = NULL;
 const char *dname = NULL;
 const char *uri_in = NULL;
+char **uri_out = data;
 
 #ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
 virReportUnsupportedError();
@@ -5985,6 +5986,23 @@ libxlDomainMigratePrepare3Params(virConnectPtr dconn,
 }
 
 static int
+libxlDomainMigratePrepare3Params(virConnectPtr dconn,
+ virTypedParameterPtr params,
+ int nparams,
+ const char *cookiein,
+ int cookieinlen,
+ char **cookieout ATTRIBUTE_UNUSED,
+ int *cookieoutlen ATTRIBUTE_UNUSED,
+ char **uri_out,
+ unsigned int flags)
+{
+return libxlDomainMigratePrepareCommon(dconn, params, nparams,
+   cookiein, cookieinlen,
+   cookieout, cookieoutlen,
+   flags, uri_out);
+}
+
+static int
 libxlDomainMigratePerform3Params(virDomainPtr dom,
  const char *dconnuri,
  virTypedParameterPtr params,
-- 
2.1.4

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

[libvirt] [PATCH v2 0/3] libxl: tunnelled migration support

[Joao Martins]

Hey!

Presented herewith is take 2 from tunnelled migration addressing all previous
comments. Changelog in individual patches (patch 1 and 2 are small refactorings
suggested in v1) Despite being functional changes mostly I had a quick round of
testing too.

Thanks,
Joao

Bob Liu (1):
  libxl: add tunnelled migration support

Joao Martins (2):
  libxl: refactor libxlDomainMigrationPrepare
  libxl: streamline top-level migrate functions

 src/libxl/libxl_driver.c|  79 --
 src/libxl/libxl_migration.c | 372 +---
 src/libxl/libxl_migration.h |   9 ++
 3 files changed, 393 insertions(+), 67 deletions(-)

-- 
2.1.4

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

Re: [libvirt] [PATCH 3/4] xenconfig: add support for more timers

[Joao Martins]

On 01/20/2017 10:17 PM, Jim Fehlig wrote:
> On 01/20/2017 05:00 AM, Joao Martins wrote:
>> On 01/20/2017 01:59 AM, Jim Fehlig wrote:
>>> Currently xenconfig only supports the hpet timer for HVM domains.
>>> Include support for tsc timer for both PV and HVM domains.
>>>
>>> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
>>> ---
>>>  src/xenconfig/xen_common.c | 87 
>>> --
>>>  1 file changed, 77 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
>>> index 7968d40..ad596d7 100644
>>> --- a/src/xenconfig/xen_common.c
>>> +++ b/src/xenconfig/xen_common.c
>>> @@ -490,6 +490,7 @@ xenParseCPUFeatures(virConfPtr conf,
>>>  unsigned long count = 0;
>>>  const char *str = NULL;
>>>  int val = 0;
>>> +virDomainTimerDefPtr timer;
>>>
>>>  if (xenConfigGetULong(conf, "vcpus", , 1) < 0)
>>>  return -1;
>>> @@ -514,6 +515,29 @@ xenParseCPUFeatures(virConfPtr conf,
>>>  if (str && (virBitmapParse(str, >cpumask, 4096) < 0))
>>>  return -1;
>>>
>>> +if (xenConfigGetString(conf, "tsc_mode", , NULL) < 0)
>>> +return -1;
>>> +
>>> +if (str) {
>>> +if (VIR_EXPAND_N(def->clock.timers, def->clock.ntimers, 1) < 0 ||
>>> +VIR_ALLOC(timer) < 0)
>>> +return -1;
>>> +
>>> +timer->name = VIR_DOMAIN_TIMER_NAME_TSC;
>>> +timer->present = 1;
>>> +timer->tickpolicy = -1;
>>> +timer->mode = VIR_DOMAIN_TIMER_MODE_AUTO;
>>> +timer->track = -1;
>>> +if (STREQ_NULLABLE(str, "always_emulate"))
>>> +timer->mode = VIR_DOMAIN_TIMER_MODE_EMULATE;
>>> +else if (STREQ_NULLABLE(str, "native"))
>>> +timer->mode = VIR_DOMAIN_TIMER_MODE_NATIVE;
>>> +else if (STREQ_NULLABLE(str, "native_paravirt"))
>>> +timer->mode = VIR_DOMAIN_TIMER_MODE_PARAVIRT;
>>> +
>>> +def->clock.timers[def->clock.ntimers - 1] = timer;
>>> +}
>>> +
>>>  if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
>>>  if (xenConfigGetBool(conf, "pae", , 1) < 0)
>>>  return -1;
>>> @@ -545,9 +569,7 @@ xenParseCPUFeatures(virConfPtr conf,
>>>  return -1;
>>>
>>>  if (val != -1) {
>>> -virDomainTimerDefPtr timer;
>>> -
>>> -if (VIR_ALLOC_N(def->clock.timers, 1) < 0 ||
>>> +if (VIR_EXPAND_N(def->clock.timers, def->clock.ntimers, 1) < 0 
>>> ||
>>>  VIR_ALLOC(timer) < 0)
>>>  return -1;
>>>
>>> @@ -557,8 +579,7 @@ xenParseCPUFeatures(virConfPtr conf,
>>>  timer->mode = -1;
>>>  timer->track = -1;
>>>
>>> -def->clock.ntimers = 1;
>>> -def->clock.timers[0] = timer;
>>> +def->clock.timers[def->clock.ntimers - 1] = timer;
>>>  }
>>>  }
>>>
>>> @@ -1584,8 +1605,9 @@ static int
>>>  xenFormatCPUFeatures(virConfPtr conf, virDomainDefPtr def)
>>>  {
>>>  size_t i;
>>> +int hvm = def->os.type == VIR_DOMAIN_OSTYPE_HVM ? 1 : 0;
>> You can probably avoid the ternary expression style with turning this into a
>> bool and do !!(def->os.type == VIR_DOMAIN_OSTYPE_HVM) or simply just
>> (def->os.type == VIR_DOMAIN_OSTYPE_HVM).
> 
> I think this is the preferred style.
> 
>> Or is it that libvirt style prefers
>> this way? Looking at the file it looks like the style you used above is kept
>> throughout this file.
> 
> I guess a bad habit was started in this file and grew though copy and past 
> :-).
Hehe :)

> 
>>
>>>
>>> -if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
>>> +if (hvm) {
>>>  if (xenConfigSetInt(conf, "pae",
>>>  (def->features[VIR_DOMAIN_FEATURE_PAE] ==
>>>  VIR_TRISTATE_SWITCH_ON) ? 1 : 0) < 0)
>>> @@ -1610,12 +1632,57 @@ xenFormatCPUFeatures(virConfPtr conf, 
>>> virDomainDefPtr def)
>>>

Re: [libvirt] [PATCH 1/4] libxl: fix timer configuration

[Joao Martins]

On 01/20/2017 09:55 PM, Jim Fehlig wrote:
> On 01/20/2017 05:00 AM, Joao Martins wrote:
>> On 01/20/2017 01:59 AM, Jim Fehlig wrote:
>>> The current logic around configuring timers in libxl based on
>>> virDomainDef object is a bit brain dead. Unsupported timers are
>>> silently ignored and tsc is only recognized if it is the first
>>> timer specified.
>>>
>>> Change the logic to reject unsupported timers and honor the tsc
>>> timer regardless of its order when multiple timers are specified.
>>>
>>> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
>>> ---
>>>  src/libxl/libxl_conf.c | 40 +++-
>>>  1 file changed, 31 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index a24f9e0..3e6d623 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -313,9 +313,10 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>>>  for (i = 0; i < virDomainDefGetVcpus(def); i++)
>>>  libxl_bitmap_set((_info->avail_vcpus), i);
>>>
>>> -if (def->clock.ntimers > 0 &&
>>> -def->clock.timers[0]->name == VIR_DOMAIN_TIMER_NAME_TSC) {
>>> -switch (def->clock.timers[0]->mode) {
>>> +for (i = 0; i < def->clock.ntimers; i++) {
>>> +switch ((virDomainTimerNameType) def->clock.timers[i]->name) {
>>> +case VIR_DOMAIN_TIMER_NAME_TSC:
>>> +switch (def->clock.timers[i]->mode) {
>>>  case VIR_DOMAIN_TIMER_MODE_NATIVE:
>>>  b_info->tsc_mode = 2;
>>>  break;
>>> @@ -324,8 +325,35 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>>>  break;
>>>  default:
>>>  b_info->tsc_mode = 1;
>>> +}
>>> +break;
>>> +
>>> +case VIR_DOMAIN_TIMER_NAME_HPET:
>>> +if (!hvm) {
>>> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
>>> +   _("unsupported timer type (name) '%s'"),
>>> +   
>>> virDomainTimerNameTypeToString(def->clock.timers[i]->name));
>>> +return -1;
>>> +}
>>> +if (def->clock.timers[i]->present == 1)
>>> +libxl_defbool_set(_info->u.hvm.hpet, 1);
>>> +break;
>>> +
>>> +case VIR_DOMAIN_TIMER_NAME_PLATFORM:
>>> +case VIR_DOMAIN_TIMER_NAME_KVMCLOCK:
>>> +case VIR_DOMAIN_TIMER_NAME_HYPERVCLOCK:
>> Interestingly, and looking at the code [toolstack:
>> tools/libxl/libxl_dom.c:hvm_set_viridian_features(), hypervisor:
>> xen/arch/x86/hvm/viridian.c:update_reference_tsc()] it looks like that to 
>> some
>> extent we support the Hyper-V Reference TSC page (Hyper-V Clock?) but it is 
>> kept
>> disabled in the viridian base features in libxl. Even if we wanted to enable 
>> it
>> would have to be more specific than adding  feature like with:
>>
>> libxl_bitmap_set(_info->u.hvm.viridian_enable,
>> LIBXL_VIRIDIAN_ENLIGHTENMENT_REFERENCE_BASE);
> 
> I'd think  OS feature would enable 
> LIBXL_VIRIDIAN_ENLIGHTENMENT_REFERENCE_BASE
Yeap.

> 
>> libxl_bitmap_set(_info->u.hvm.viridian_enable,
>> LIBXL_VIRIDIAN_ENLIGHTENMENT_REFERENCE_TSC);
> 
> And this one would be enabled with
> 
>
>  
>
> 
> Is that correct? Should a hypervclock timer also include 
> LIBXL_VIRIDIAN_ENLIGHTENMENT_TIME_REF_COUNT?
IIUC the TIME_REF_COUNT enlightenment is for older versions of windwos, whereas
REFERENCE_TSC is the newer one and most performant. Presumably TIME_REF is
included in the base viridian features.

> 
>> and perhaps behind "#ifdef LIBXL_VIRIDIAN_ENLIGHTENMENT_REFERENCE_TSC" as 
>> this
>> is only supported since Xen 4.6.0? And I think it would work with tsc_mode 
>> not
>> being emulated? Relevant commit on Xen is dd94caca5 ("x86/viridian: add
>> Partition Reference Time enlightenment") Anyhow this is probably not in the
>> context of this series, just food for thought in case we want to have in the 
>> future.
> 
> Good points, and agree they could be addressed in a followup series that 
> enables 
> viridian enlightenments.
> 
>>
>>> +case VIR_DOMAIN_TIMER_NAME_RTC:
>>> +case VIR_DOMAIN_TIMER_NAM

Re: [libvirt] [PATCH 3/4] xenconfig: add support for more timers

[Joao Martins]

On 01/20/2017 01:59 AM, Jim Fehlig wrote:
> Currently xenconfig only supports the hpet timer for HVM domains.
> Include support for tsc timer for both PV and HVM domains.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  src/xenconfig/xen_common.c | 87 
> --
>  1 file changed, 77 insertions(+), 10 deletions(-)
> 
> diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
> index 7968d40..ad596d7 100644
> --- a/src/xenconfig/xen_common.c
> +++ b/src/xenconfig/xen_common.c
> @@ -490,6 +490,7 @@ xenParseCPUFeatures(virConfPtr conf,
>  unsigned long count = 0;
>  const char *str = NULL;
>  int val = 0;
> +virDomainTimerDefPtr timer;
>  
>  if (xenConfigGetULong(conf, "vcpus", , 1) < 0)
>  return -1;
> @@ -514,6 +515,29 @@ xenParseCPUFeatures(virConfPtr conf,
>  if (str && (virBitmapParse(str, >cpumask, 4096) < 0))
>  return -1;
>  
> +if (xenConfigGetString(conf, "tsc_mode", , NULL) < 0)
> +return -1;
> +
> +if (str) {
> +if (VIR_EXPAND_N(def->clock.timers, def->clock.ntimers, 1) < 0 ||
> +VIR_ALLOC(timer) < 0)
> +return -1;
> +
> +timer->name = VIR_DOMAIN_TIMER_NAME_TSC;
> +timer->present = 1;
> +timer->tickpolicy = -1;
> +timer->mode = VIR_DOMAIN_TIMER_MODE_AUTO;
> +timer->track = -1;
> +if (STREQ_NULLABLE(str, "always_emulate"))
> +timer->mode = VIR_DOMAIN_TIMER_MODE_EMULATE;
> +else if (STREQ_NULLABLE(str, "native"))
> +timer->mode = VIR_DOMAIN_TIMER_MODE_NATIVE;
> +else if (STREQ_NULLABLE(str, "native_paravirt"))
> +timer->mode = VIR_DOMAIN_TIMER_MODE_PARAVIRT;
> +
> +def->clock.timers[def->clock.ntimers - 1] = timer;
> +}
> +
>  if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
>  if (xenConfigGetBool(conf, "pae", , 1) < 0)
>  return -1;
> @@ -545,9 +569,7 @@ xenParseCPUFeatures(virConfPtr conf,
>  return -1;
>  
>  if (val != -1) {
> -virDomainTimerDefPtr timer;
> -
> -if (VIR_ALLOC_N(def->clock.timers, 1) < 0 ||
> +if (VIR_EXPAND_N(def->clock.timers, def->clock.ntimers, 1) < 0 ||
>  VIR_ALLOC(timer) < 0)
>  return -1;
>  
> @@ -557,8 +579,7 @@ xenParseCPUFeatures(virConfPtr conf,
>  timer->mode = -1;
>  timer->track = -1;
>  
> -def->clock.ntimers = 1;
> -def->clock.timers[0] = timer;
> +def->clock.timers[def->clock.ntimers - 1] = timer;
>  }
>  }
>  
> @@ -1584,8 +1605,9 @@ static int
>  xenFormatCPUFeatures(virConfPtr conf, virDomainDefPtr def)
>  {
>  size_t i;
> +int hvm = def->os.type == VIR_DOMAIN_OSTYPE_HVM ? 1 : 0;
You can probably avoid the ternary expression style with turning this into a
bool and do !!(def->os.type == VIR_DOMAIN_OSTYPE_HVM) or simply just
(def->os.type == VIR_DOMAIN_OSTYPE_HVM). Or is it that libvirt style prefers
this way? Looking at the file it looks like the style you used above is kept
throughout this file.

>  
> -if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
> +if (hvm) {
>  if (xenConfigSetInt(conf, "pae",
>  (def->features[VIR_DOMAIN_FEATURE_PAE] ==
>  VIR_TRISTATE_SWITCH_ON) ? 1 : 0) < 0)
> @@ -1610,12 +1632,57 @@ xenFormatCPUFeatures(virConfPtr conf, virDomainDefPtr 
> def)
>  (def->features[VIR_DOMAIN_FEATURE_VIRIDIAN] ==
>   VIR_TRISTATE_SWITCH_ON) ? 1 : 0) < 0)
>  return -1;
> +}
>  
> -for (i = 0; i < def->clock.ntimers; i++) {
> -if (def->clock.timers[i]->name == VIR_DOMAIN_TIMER_NAME_HPET &&
> -def->clock.timers[i]->present != -1 &&
> -xenConfigSetInt(conf, "hpet", def->clock.timers[i]->present) 
> < 0)
> +for (i = 0; i < def->clock.ntimers; i++) {
> +switch ((virDomainTimerNameType) def->clock.timers[i]->name) {
> +case VIR_DOMAIN_TIMER_NAME_TSC:
> +switch (def->clock.timers[i]->mode) {
> +case VIR_DOMAIN_TIMER_MODE_NATIVE:
> +if (xenConfigSetString(conf, "tsc_mode", "native") < 0)
> +return -1;
> +break;
> +case VIR_DOMAIN_TIMER_MODE_PARAVIRT:
> +if (xenConfigSetString(conf, "tsc_mode", "native_paravirt") 
> < 0)
> +return -1;
> +break;
> +case VIR_DOMAIN_TIMER_MODE_EMULATE:
> +if (xenConfigSetString(conf, "tsc_mode", "always_emulate") < 
> 0)
> +return -1;
> +break;
> +default:
> +if (xenConfigSetString(conf, "tsc_mode", "default") < 0)
> +return -1;
> +}
> +break;
> +
> +case VIR_DOMAIN_TIMER_NAME_HPET:
> +if 

Re: [libvirt] [PATCH 1/4] libxl: fix timer configuration

[Joao Martins]

On 01/20/2017 01:59 AM, Jim Fehlig wrote:
> The current logic around configuring timers in libxl based on
> virDomainDef object is a bit brain dead. Unsupported timers are
> silently ignored and tsc is only recognized if it is the first
> timer specified.
> 
> Change the logic to reject unsupported timers and honor the tsc
> timer regardless of its order when multiple timers are specified.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  src/libxl/libxl_conf.c | 40 +++-
>  1 file changed, 31 insertions(+), 9 deletions(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index a24f9e0..3e6d623 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -313,9 +313,10 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>  for (i = 0; i < virDomainDefGetVcpus(def); i++)
>  libxl_bitmap_set((_info->avail_vcpus), i);
>  
> -if (def->clock.ntimers > 0 &&
> -def->clock.timers[0]->name == VIR_DOMAIN_TIMER_NAME_TSC) {
> -switch (def->clock.timers[0]->mode) {
> +for (i = 0; i < def->clock.ntimers; i++) {
> +switch ((virDomainTimerNameType) def->clock.timers[i]->name) {
> +case VIR_DOMAIN_TIMER_NAME_TSC:
> +switch (def->clock.timers[i]->mode) {
>  case VIR_DOMAIN_TIMER_MODE_NATIVE:
>  b_info->tsc_mode = 2;
>  break;
> @@ -324,8 +325,35 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>  break;
>  default:
>  b_info->tsc_mode = 1;
> +}
> +break;
> +
> +case VIR_DOMAIN_TIMER_NAME_HPET:
> +if (!hvm) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> +   _("unsupported timer type (name) '%s'"),
> +   
> virDomainTimerNameTypeToString(def->clock.timers[i]->name));
> +return -1;
> +}
> +if (def->clock.timers[i]->present == 1)
> +libxl_defbool_set(_info->u.hvm.hpet, 1);
> +break;
> +
> +case VIR_DOMAIN_TIMER_NAME_PLATFORM:
> +case VIR_DOMAIN_TIMER_NAME_KVMCLOCK:
> +case VIR_DOMAIN_TIMER_NAME_HYPERVCLOCK:
Interestingly, and looking at the code [toolstack:
tools/libxl/libxl_dom.c:hvm_set_viridian_features(), hypervisor:
xen/arch/x86/hvm/viridian.c:update_reference_tsc()] it looks like that to some
extent we support the Hyper-V Reference TSC page (Hyper-V Clock?) but it is kept
disabled in the viridian base features in libxl. Even if we wanted to enable it
would have to be more specific than adding  feature like with:

libxl_bitmap_set(_info->u.hvm.viridian_enable,
LIBXL_VIRIDIAN_ENLIGHTENMENT_REFERENCE_BASE);

libxl_bitmap_set(_info->u.hvm.viridian_enable,
LIBXL_VIRIDIAN_ENLIGHTENMENT_REFERENCE_TSC);

and perhaps behind "#ifdef LIBXL_VIRIDIAN_ENLIGHTENMENT_REFERENCE_TSC" as this
is only supported since Xen 4.6.0? And I think it would work with tsc_mode not
being emulated? Relevant commit on Xen is dd94caca5 ("x86/viridian: add
Partition Reference Time enlightenment") Anyhow this is probably not in the
context of this series, just food for thought in case we want to have in the 
future.

> +case VIR_DOMAIN_TIMER_NAME_RTC:
> +case VIR_DOMAIN_TIMER_NAME_PIT:
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> +   _("unsupported timer type (name) '%s'"),
> +   
> virDomainTimerNameTypeToString(def->clock.timers[i]->name));
> +return -1;
> +
> +case VIR_DOMAIN_TIMER_NAME_LAST:
> +break;
>  }
>  }
> +
Spurious whitespace? Or perhaps it was purposely added?

>  b_info->sched_params.weight = 1000;
>  b_info->max_memkb = virDomainDefGetMemoryInitial(def);
>  b_info->target_memkb = def->mem.cur_balloon;
> @@ -341,12 +369,6 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
>  libxl_defbool_set(_info->u.hvm.acpi,
>def->features[VIR_DOMAIN_FEATURE_ACPI] ==
>VIR_TRISTATE_SWITCH_ON);
> -for (i = 0; i < def->clock.ntimers; i++) {
> -if (def->clock.timers[i]->name == VIR_DOMAIN_TIMER_NAME_HPET &&
> -def->clock.timers[i]->present == 1) {
> -libxl_defbool_set(_info->u.hvm.hpet, 1);
> -}
> -}
>  
>  if (def->nsounds > 0) {
>  /*
> 

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

Re: [libvirt] [PATCH] tests: fix QED disk test in xlconfigtest

[Joao Martins]

On 01/16/2017 06:45 PM, Jim Fehlig wrote:
> When LIBXL_HAVE_QED is defined, xlconfigtest fails
> 
>  9) Xen XL-2-XML Format disk-qed  ... command line: config parsing error
>  in disk specification: no vdev specified in
>  
> `target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw'
> FAILED
> 
> As per the xl-disk-configuration(5) man page, target= must come
> last in the disk specification when specified by name:
> 
> When this parameter is specified by name, ie with the target=
> syntax in the configuration file, it consumes the whole rest of the
> DISKSPEC including trailing whitespaces.  Therefore in that case
> it must come last.
> 
> Change tests/xlconfigdata/test-disk-qed.cfg to adhere to this
> restriction.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
Looks like Xen's osstest job doesn't run "make check" on the libvirt test case.
FWIW:

Acked-by: Joao Martins <joao.m.mart...@oracle.com>

> ---
>  tests/xlconfigdata/test-disk-qed.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/xlconfigdata/test-disk-qed.cfg 
> b/tests/xlconfigdata/test-disk-qed.cfg
> index ee904e0..7842176 100644
> --- a/tests/xlconfigdata/test-disk-qed.cfg
> +++ b/tests/xlconfigdata/test-disk-qed.cfg
> @@ -22,4 +22,4 @@ parallel = "none"
>  serial = "none"
>  builder = "hvm"
>  boot = "d"
> -disk = [ 
> "target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw"
>  ]
> +disk = [ 
> "format=qed,backendtype=qdisk,vdev=hda,access=rw,target=/var/lib/libvirt/images/XenGuest2"
>  ]
> 

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

[libvirt] [PATCH] news: document libxl HVM network attach fix

[Joao Martins]

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 docs/news.xml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index 92e39f9..c19 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -204,6 +204,16 @@
   domain definition.
 
   
+  
+
+  libxl: reverse defaults on HVM net device attach
+
+
+  Fixes network interface attach for HVM domains when no model is
+  specified. Emulated hotplug isn't yet supported and hence we should
+  default to the general working scenario.
+
+  
 
   
   
-- 
2.1.4

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

Re: [libvirt] [PATCH v4] libxl: define a per-domain logger.

[Joao Martins]

Hey Cedric,

On 01/10/2017 09:03 AM, Cédric Bosdonnat wrote:
> libxl doesn't provide a way to write one log for each domain. Thus
> we need to demux the messages. If our logger doesn't know to which
> domain to attribute a message, then it will write it to the default
> log file.
> 
> Starting with Xen 4.9 (commit f9858025 and following), libxl will
> write the domain ID in an easy to grab manner. The logger introduced
> by this commit will use it to demux the libxl log messages.
> 
> Thanks to the default log file, this logger will also work with older
> versions of Xen.
This is great stuff!

BTW, while applying the patch in my local repo, I noticed some issues (and
confirmed make syntax-check is failing with them as well). But I assume those
could be fixed on commit.

Joao

> ---
>  * v4: delay the log file opening to the first message write.
> 
>  * v3: add JSON-formatted libxl_domain_config to the newly opened
>file when creating a guest.
> 
>  * v2: addressed Jim's comments
> 
>  src/Makefile.am  |   1 +
>  src/libxl/libxl_conf.c   |  38 +--
>  src/libxl/libxl_conf.h   |   4 +-
>  src/libxl/libxl_domain.c |   7 ++
>  src/libxl/libxl_driver.c |   2 +
>  src/libxl/libxl_logger.c | 257 
> +++
>  src/libxl/libxl_logger.h |  40 
>  7 files changed, 312 insertions(+), 37 deletions(-)
>  create mode 100644 src/libxl/libxl_logger.c
>  create mode 100644 src/libxl/libxl_logger.h
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 0dd2faaf6..58e3108a6 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -851,6 +851,7 @@ LIBXL_DRIVER_SOURCES =
> \
>   libxl/libxl_capabilities.c libxl/libxl_capabilities.h   \
>   libxl/libxl_domain.c libxl/libxl_domain.h   \
>   libxl/libxl_driver.c libxl/libxl_driver.h   \
> + libxl/libxl_logger.c libxl/libxl_logger.h   \
>   libxl/libxl_migration.c libxl/libxl_migration.h
>  
>  UML_DRIVER_SOURCES = \
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index b569ddad8..ac83b51c7 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -76,9 +76,7 @@ libxlDriverConfigDispose(void *obj)
>  
>  virObjectUnref(cfg->caps);
>  libxl_ctx_free(cfg->ctx);
> -xtl_logger_destroy(cfg->logger);
> -if (cfg->logger_file)
> -VIR_FORCE_FCLOSE(cfg->logger_file);
> +libxlLoggerFree(cfg->logger);
>  
>  VIR_FREE(cfg->configDir);
>  VIR_FREE(cfg->autostartDir);
> @@ -1356,8 +1354,6 @@ libxlDriverConfigPtr
>  libxlDriverConfigNew(void)
>  {
>  libxlDriverConfigPtr cfg;
> -char *log_file = NULL;
> -xentoollog_level log_level = XTL_DEBUG;
>  char ebuf[1024];
>  unsigned int free_mem;
>  
> @@ -1386,9 +1382,6 @@ libxlDriverConfigNew(void)
>  if (VIR_STRDUP(cfg->channelDir, LIBXL_CHANNEL_DIR) < 0)
>  goto error;
>  
> -if (virAsprintf(_file, "%s/libxl-driver.log", cfg->logDir) < 0)
> -goto error;
> -
>  if (virFileMakePath(cfg->logDir) < 0) {
>  virReportError(VIR_ERR_INTERNAL_ERROR,
> _("failed to create log dir '%s': %s"),
> @@ -1397,37 +1390,13 @@ libxlDriverConfigNew(void)
>  goto error;
>  }
>  
> -if ((cfg->logger_file = fopen(log_file, "a")) == NULL)  {
> -VIR_ERROR(_("Failed to create log file '%s': %s"),
> -  log_file, virStrerror(errno, ebuf, sizeof(ebuf)));
> -goto error;
> -}
> -VIR_FREE(log_file);
> -
> -switch (virLogGetDefaultPriority()) {
> -case VIR_LOG_DEBUG:
> -log_level = XTL_DEBUG;
> -break;
> -case VIR_LOG_INFO:
> -log_level = XTL_INFO;
> -break;
> -case VIR_LOG_WARN:
> -log_level = XTL_WARN;
> -break;
> -case VIR_LOG_ERROR:
> -log_level = XTL_ERROR;
> -break;
> -}
> -
> -cfg->logger =
> -(xentoollog_logger *)xtl_createlogger_stdiostream(cfg->logger_file,
> -  log_level, XTL_STDIOSTREAM_SHOW_DATE);
> +cfg->logger = libxlLoggerNew(cfg->logDir, virLogGetDefaultPriority());
>  if (!cfg->logger) {
>  VIR_ERROR(_("cannot create logger for libxenlight, disabling 
> driver"));
>  goto error;
>  }
>  
> -if (libxl_ctx_alloc(>ctx, LIBXL_VERSION, 0, cfg->logger)) {
> +if (libxl_ctx_alloc(>ctx, LIBXL_VERSION, 0, (xentoollog_logger 
> *)cfg->logger)) {
>  VIR_ERROR(_("cannot initialize libxenlight context, probably not "
>  "running in a Xen Dom0, disabling driver"));
>  goto error;
> @@ -1478,7 +1447,6 @@ libxlDriverConfigNew(void)
>  return cfg;
>  
>   error:
> -VIR_FREE(log_file);
>  virObjectUnref(cfg);
>  return NULL;
>  }
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 

Re: [libvirt] [PATCH v1] libxl: reverse defaults on HVM net device attach

[Joao Martins]

On 12/14/2016 08:53 PM, Jim Fehlig wrote:
> On 12/14/2016 03:53 AM, Joao Martins wrote:
>> libvirt libxl picks its own default with respect to the default NIC
>> to use. libxlMakeNic is the one responsible for this and on boot it
>> picks LIBXL_NIC_TYPE_VIF_IOEMU for HVM domains such that it accomodates
>> both PV and emulated one. The good behaving guest at boot will then
>> select the pv and unplug the emulated device.
>>
>> Now, on HVM when attaching an interface it will pick the same default
>> that is LIBXL_NIC_TYPE_VIF_IOEMU which as a result will fail the attach
>> (see xen commit 32e9d0f ("libxl: nic type defaults to vif in hotplug for
>> hvm guest"). Xen doesn't yet support the hotplug of emulated devices,
>> but we don't want to rule out that case either, which might get support
>> in the future. Hence we simply reverse the defaults when we are
>> attaching the interface which allows libvirt to prefer the PV nic first
>> without adding "model='netfront'" following the same pattern as above
>> commit. Also to avoid ruling out the emulated one we set to
>> LIBXL_NIC_TYPE_IOEMU when setting a model type that is not 'netfront'.
>>
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>> Signed-off-by: Jim Fehlig <jfeh...@suse.com>
>> ---
>> Since RFC:
>> - Joao: Add mention to HVM domains in the first paragraph of commit
>> message.
>> - Jim: Add comment about libxl_device_nic type inner workings
>> - Jim: Prevent attach on PV when model != netfront
>> - Joao: Remove now unused ioemu_nic variable
>> - Joao: Append one small paragraph about why we mimic xl/libxl
>> ---
>>  src/libxl/libxl_conf.c   | 39 +++
>>  src/libxl/libxl_conf.h   |  3 ++-
>>  src/libxl/libxl_driver.c |  2 +-
>>  3 files changed, 34 insertions(+), 10 deletions(-)
> 
> ACK and pushed.
Thank you!

Joao

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

[libvirt] [PATCH v1] libxl: reverse defaults on HVM net device attach

[Joao Martins]

libvirt libxl picks its own default with respect to the default NIC
to use. libxlMakeNic is the one responsible for this and on boot it
picks LIBXL_NIC_TYPE_VIF_IOEMU for HVM domains such that it accomodates
both PV and emulated one. The good behaving guest at boot will then
select the pv and unplug the emulated device.

Now, on HVM when attaching an interface it will pick the same default
that is LIBXL_NIC_TYPE_VIF_IOEMU which as a result will fail the attach
(see xen commit 32e9d0f ("libxl: nic type defaults to vif in hotplug for
hvm guest"). Xen doesn't yet support the hotplug of emulated devices,
but we don't want to rule out that case either, which might get support
in the future. Hence we simply reverse the defaults when we are
attaching the interface which allows libvirt to prefer the PV nic first
without adding "model='netfront'" following the same pattern as above
commit. Also to avoid ruling out the emulated one we set to
LIBXL_NIC_TYPE_IOEMU when setting a model type that is not 'netfront'.

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
Signed-off-by: Jim Fehlig <jfeh...@suse.com>
---
Since RFC:
- Joao: Add mention to HVM domains in the first paragraph of commit
message.
- Jim: Add comment about libxl_device_nic type inner workings
- Jim: Prevent attach on PV when model != netfront
- Joao: Remove now unused ioemu_nic variable
- Joao: Append one small paragraph about why we mimic xl/libxl
---
 src/libxl/libxl_conf.c   | 39 +++
 src/libxl/libxl_conf.h   |  3 ++-
 src/libxl/libxl_driver.c |  2 +-
 3 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index dcf8e7e..9515e2a 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -881,9 +881,9 @@ libxlMakeDiskList(virDomainDefPtr def, libxl_domain_config 
*d_config)
 int
 libxlMakeNic(virDomainDefPtr def,
  virDomainNetDefPtr l_nic,
- libxl_device_nic *x_nic)
+ libxl_device_nic *x_nic,
+ bool attach)
 {
-bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM;
 virDomainNetType actual_type = virDomainNetGetActualType(l_nic);
 virNetworkPtr network = NULL;
 virConnectPtr conn = NULL;
@@ -907,16 +907,39 @@ libxlMakeNic(virDomainDefPtr def,
 
 virMacAddrGetRaw(_nic->mac, x_nic->mac);
 
-if (ioemu_nic)
-x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
-else
-x_nic->nictype = LIBXL_NIC_TYPE_VIF;
-
+/*
+ * The nictype field of libxl_device_nic structure tells Xen which type of
+ * NIC device to create for the domain. LIBXL_NIC_TYPE_VIF specifies a
+ * PV NIC. LIBXL_NIC_TYPE_VIF_IOEMU specifies a PV and emulated NIC,
+ * allowing the domain to choose which NIC to use and unplug the unused
+ * one. LIBXL_NIC_TYPE_VIF_IOEMU is only valid for HVM domains. Further,
+ * if hotplugging the NIC, emulated NICs are currently not supported.
+ * Alternatively one could set LIBXL_NIC_TYPE_UNKNOWN and let libxl decide,
+ * but its behaviour might not be consistent across all libvirt supported
+ * versions. The other nictype values are well established already, hence
+ * we manually select our own default and mimic xl/libxl behaviour starting
+ * xen commit 32e9d0f ("libxl: nic type defaults to vif in hotplug for
+ * hvm guest").
+ */
 if (l_nic->model) {
+if (def->os.type == VIR_DOMAIN_OSTYPE_XEN &&
+STRNEQ(l_nic->model, "netfront")) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("only model 'netfront' is supported for "
+ "Xen PV domains"));
+return -1;
+}
 if (VIR_STRDUP(x_nic->model, l_nic->model) < 0)
 goto cleanup;
 if (STREQ(l_nic->model, "netfront"))
 x_nic->nictype = LIBXL_NIC_TYPE_VIF;
+else
+x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
+} else {
+if (def->os.type == VIR_DOMAIN_OSTYPE_HVM && !attach)
+x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
+else
+x_nic->nictype = LIBXL_NIC_TYPE_VIF;
 }
 
 if (VIR_STRDUP(x_nic->ifname, l_nic->ifname) < 0)
@@ -1047,7 +1070,7 @@ libxlMakeNicList(virDomainDefPtr def,  
libxl_domain_config *d_config)
 if (virDomainNetGetActualType(l_nics[i]) == 
VIR_DOMAIN_NET_TYPE_HOSTDEV)
 continue;
 
-if (libxlMakeNic(def, l_nics[i], _nics[nvnics]))
+if (libxlMakeNic(def, l_nics[i], _nics[nvnics], false))
 goto error;
 /*
  * The devid (at least right now) will not get initialized by
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 0ea76b4..851f3af 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_

Re: [libvirt] [PATCH RFC] libxl: reverse defaults on HVM net device attach

[Joao Martins]

On 12/13/2016 03:24 AM, Jim Fehlig wrote:
> On 12/09/2016 04:35 AM, Joao Martins wrote:
>> libvirt libxl picks its own default with respect to the default NIC
>> to use. libxlMakeNic is the one responsible for this and on boot it
>> picks LIBXL_NIC_TYPE_VIF_IOEMU such that it accomodates both PV and
>> emulated one. The good behaving guest at boot will then select the pv
>> and unplug the emulated device.
>>
>> Now, on HVM when attaching an interface it will pick the same default
>> that is LIBXL_NIC_TYPE_VIF_IOEMU which as a result will fail the attach
>> (see xen commit 32e9d0f ("libxl: nic type defaults to vif in hotplug for
>> hvm guest"). Xen doesn't yet support the hotplug of emulated devices,
>> but we don't want to rule out that case either, which might get support
>> in the future. Hence we simply reverse the defaults when we are
>> attaching the interface which allows libvirt to prefer the PV nic first
>> without adding "model='netfront'" following the same pattern as above
>> commit. Also to avoid ruling out the emulated one we set to
>> LIBXL_NIC_TYPE_IOEMU when setting a model type that is not 'netfront'.
>>
>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>> ---
>>
>> This allows Openstack to attach network interfaces, which currently
>> is broken on libxl if it doesn't set model 'netfront'. I am not sure
>> whether this is the best way (hence RFC) or if users should really be
>> setting the model='netfront' when attaching devices. But sounds to me
>> that it would be better to have by default the supported, and if users
>> want emulated attach to specify a nic model. Thoughts?
> 
> Agreed. I think it is best to mimic the behavior of xl/libxl.
Cool, Thanks for the feedback.

> 
>> ---
>>  src/libxl/libxl_conf.c   | 9 ++---
>>  src/libxl/libxl_conf.h   | 3 ++-
>>  src/libxl/libxl_driver.c | 2 +-
>>  3 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>> index dcf8e7e..50aa958 100644
>> --- a/src/libxl/libxl_conf.c
>> +++ b/src/libxl/libxl_conf.c
>> @@ -881,9 +881,10 @@ libxlMakeDiskList(virDomainDefPtr def, 
>> libxl_domain_config *d_config)
>>  int
>>  libxlMakeNic(virDomainDefPtr def,
>>   virDomainNetDefPtr l_nic,
>> - libxl_device_nic *x_nic)
>> + libxl_device_nic *x_nic,
>> + bool attach)
>>  {
>> -bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM;
>> +bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM && !attach;
>>  virDomainNetType actual_type = virDomainNetGetActualType(l_nic);
>>  virNetworkPtr network = NULL;
>>  virConnectPtr conn = NULL;
>> @@ -917,6 +918,8 @@ libxlMakeNic(virDomainDefPtr def,
>>  goto cleanup;
>>  if (STREQ(l_nic->model, "netfront"))
>>  x_nic->nictype = LIBXL_NIC_TYPE_VIF;
>> +else
>> +x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
>>  }
>>
>>  if (VIR_STRDUP(x_nic->ifname, l_nic->ifname) < 0)
> 
> This logic has gotten a bit confusing for the casual reader not familiar with 
> the Xen behavior. It is late here and my eyes are getting heavy, but what do 
> you
> think about replacing this hunk with something like the below? Feel free to 
> suggest something more clear and succinct, but at minimum I think a comment 
> describing the Xen behavior is warranted.
The patch looks good, just two minor comments below. I can submit another
version, and as I am taking your changes - may I add your SoB tag?

> Regards,
> Jim
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index dcf8e7e..6650b21 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -881,7 +881,8 @@ libxlMakeDiskList(virDomainDefPtr def, 
> libxl_domain_config 
> *d_config)
>   int
>   libxlMakeNic(virDomainDefPtr def,
>virDomainNetDefPtr l_nic,
> - libxl_device_nic *x_nic)
> + libxl_device_nic *x_nic,
> + bool attach)
>   {
>   bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM;
 ^ This is no longer needed after this chunk.

>   virDomainNetType actual_type = virDomainNetGetActualType(l_nic);
> @@ -907,16 +908,33 @@ libxlMakeNic(virDomainDefPtr def,
> 
>   virMacAddrGetRaw(_nic->mac, x_nic->mac);
> 
> -if (ioemu_nic)
> -x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
> -else
> -x_nic->nictype = LIBXL_NIC_TYPE_VIF

Re: [libvirt] [PATCH RFC] libxl: reverse defaults on HVM net device attach

[Joao Martins]

On 12/09/2016 11:35 AM, Joao Martins wrote:
> libvirt libxl picks its own default with respect to the default NIC
> to use. libxlMakeNic is the one responsible for this and on boot it
> picks LIBXL_NIC_TYPE_VIF_IOEMU such that it accomodates both PV and
> emulated one. The good behaving guest at boot will then select the pv
> and unplug the emulated device.
Short note, in this paragraph I meant for HVM guest. For PV this isn't
applicable. I can correct the commit message and resend after
comments (depending ofc if folks think this is right way to go).

> Now, on HVM when attaching an interface it will pick the same default
> that is LIBXL_NIC_TYPE_VIF_IOEMU which as a result will fail the attach
> (see xen commit 32e9d0f ("libxl: nic type defaults to vif in hotplug for
> hvm guest"). Xen doesn't yet support the hotplug of emulated devices,
> but we don't want to rule out that case either, which might get support
> in the future. Hence we simply reverse the defaults when we are
> attaching the interface which allows libvirt to prefer the PV nic first
> without adding "model='netfront'" following the same pattern as above
> commit. Also to avoid ruling out the emulated one we set to
> LIBXL_NIC_TYPE_IOEMU when setting a model type that is not 'netfront'.
> 
> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
> ---
> 
> This allows Openstack to attach network interfaces, which currently
> is broken on libxl if it doesn't set model 'netfront'. I am not sure
> whether this is the best way (hence RFC) or if users should really be
> setting the model='netfront' when attaching devices. But sounds to me
> that it would be better to have by default the supported, and if users
> want emulated attach to specify a nic model. Thoughts?
> ---
>  src/libxl/libxl_conf.c   | 9 ++---
>  src/libxl/libxl_conf.h   | 3 ++-
>  src/libxl/libxl_driver.c | 2 +-
>  3 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index dcf8e7e..50aa958 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -881,9 +881,10 @@ libxlMakeDiskList(virDomainDefPtr def, 
> libxl_domain_config *d_config)
>  int
>  libxlMakeNic(virDomainDefPtr def,
>   virDomainNetDefPtr l_nic,
> - libxl_device_nic *x_nic)
> + libxl_device_nic *x_nic,
> + bool attach)
>  {
> -bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM;
> +bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM && !attach;
>  virDomainNetType actual_type = virDomainNetGetActualType(l_nic);
>  virNetworkPtr network = NULL;
>  virConnectPtr conn = NULL;
> @@ -917,6 +918,8 @@ libxlMakeNic(virDomainDefPtr def,
>  goto cleanup;
>  if (STREQ(l_nic->model, "netfront"))
>  x_nic->nictype = LIBXL_NIC_TYPE_VIF;
> +else
> +x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
>  }
>  
>  if (VIR_STRDUP(x_nic->ifname, l_nic->ifname) < 0)
> @@ -1047,7 +1050,7 @@ libxlMakeNicList(virDomainDefPtr def,  
> libxl_domain_config *d_config)
>  if (virDomainNetGetActualType(l_nics[i]) == 
> VIR_DOMAIN_NET_TYPE_HOSTDEV)
>  continue;
>  
> -if (libxlMakeNic(def, l_nics[i], _nics[nvnics]))
> +if (libxlMakeNic(def, l_nics[i], _nics[nvnics], false))
>  goto error;
>  /*
>   * The devid (at least right now) will not get initialized by
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 0ea76b4..851f3af 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -178,7 +178,8 @@ libxlMakeDisk(virDomainDiskDefPtr l_dev, 
> libxl_device_disk *x_dev);
>  int
>  libxlMakeNic(virDomainDefPtr def,
>   virDomainNetDefPtr l_nic,
> - libxl_device_nic *x_nic);
> + libxl_device_nic *x_nic,
> + bool attach);
>  int
>  libxlMakeVfb(virPortAllocatorPtr graphicsports,
>   virDomainGraphicsDefPtr l_vfb, libxl_device_vfb *x_vfb);
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index b19b17e..7e5d9b6 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -3379,7 +3379,7 @@ libxlDomainAttachNetDevice(libxlDriverPrivatePtr driver,
>  goto cleanup;
>  }
>  
> -if (libxlMakeNic(vm->def, net, ) < 0)
> +if (libxlMakeNic(vm->def, net, , true) < 0)
>  goto cleanup;
>  
>  if (libxl_device_nic_add(cfg->ctx, vm->def->id, , 0)) {
> 

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

[libvirt] [PATCH RFC] libxl: reverse defaults on HVM net device attach

[Joao Martins]

libvirt libxl picks its own default with respect to the default NIC
to use. libxlMakeNic is the one responsible for this and on boot it
picks LIBXL_NIC_TYPE_VIF_IOEMU such that it accomodates both PV and
emulated one. The good behaving guest at boot will then select the pv
and unplug the emulated device.

Now, on HVM when attaching an interface it will pick the same default
that is LIBXL_NIC_TYPE_VIF_IOEMU which as a result will fail the attach
(see xen commit 32e9d0f ("libxl: nic type defaults to vif in hotplug for
hvm guest"). Xen doesn't yet support the hotplug of emulated devices,
but we don't want to rule out that case either, which might get support
in the future. Hence we simply reverse the defaults when we are
attaching the interface which allows libvirt to prefer the PV nic first
without adding "model='netfront'" following the same pattern as above
commit. Also to avoid ruling out the emulated one we set to
LIBXL_NIC_TYPE_IOEMU when setting a model type that is not 'netfront'.

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---

This allows Openstack to attach network interfaces, which currently
is broken on libxl if it doesn't set model 'netfront'. I am not sure
whether this is the best way (hence RFC) or if users should really be
setting the model='netfront' when attaching devices. But sounds to me
that it would be better to have by default the supported, and if users
want emulated attach to specify a nic model. Thoughts?
---
 src/libxl/libxl_conf.c   | 9 ++---
 src/libxl/libxl_conf.h   | 3 ++-
 src/libxl/libxl_driver.c | 2 +-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index dcf8e7e..50aa958 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -881,9 +881,10 @@ libxlMakeDiskList(virDomainDefPtr def, libxl_domain_config 
*d_config)
 int
 libxlMakeNic(virDomainDefPtr def,
  virDomainNetDefPtr l_nic,
- libxl_device_nic *x_nic)
+ libxl_device_nic *x_nic,
+ bool attach)
 {
-bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM;
+bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM && !attach;
 virDomainNetType actual_type = virDomainNetGetActualType(l_nic);
 virNetworkPtr network = NULL;
 virConnectPtr conn = NULL;
@@ -917,6 +918,8 @@ libxlMakeNic(virDomainDefPtr def,
 goto cleanup;
 if (STREQ(l_nic->model, "netfront"))
 x_nic->nictype = LIBXL_NIC_TYPE_VIF;
+else
+x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
 }
 
 if (VIR_STRDUP(x_nic->ifname, l_nic->ifname) < 0)
@@ -1047,7 +1050,7 @@ libxlMakeNicList(virDomainDefPtr def,  
libxl_domain_config *d_config)
 if (virDomainNetGetActualType(l_nics[i]) == 
VIR_DOMAIN_NET_TYPE_HOSTDEV)
 continue;
 
-if (libxlMakeNic(def, l_nics[i], _nics[nvnics]))
+if (libxlMakeNic(def, l_nics[i], _nics[nvnics], false))
 goto error;
 /*
  * The devid (at least right now) will not get initialized by
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 0ea76b4..851f3af 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -178,7 +178,8 @@ libxlMakeDisk(virDomainDiskDefPtr l_dev, libxl_device_disk 
*x_dev);
 int
 libxlMakeNic(virDomainDefPtr def,
  virDomainNetDefPtr l_nic,
- libxl_device_nic *x_nic);
+ libxl_device_nic *x_nic,
+ bool attach);
 int
 libxlMakeVfb(virPortAllocatorPtr graphicsports,
  virDomainGraphicsDefPtr l_vfb, libxl_device_vfb *x_vfb);
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index b19b17e..7e5d9b6 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -3379,7 +3379,7 @@ libxlDomainAttachNetDevice(libxlDriverPrivatePtr driver,
 goto cleanup;
 }
 
-if (libxlMakeNic(vm->def, net, ) < 0)
+if (libxlMakeNic(vm->def, net, , true) < 0)
 goto cleanup;
 
 if (libxl_device_nic_add(cfg->ctx, vm->def->id, , 0)) {
-- 
2.1.4

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

Re: [libvirt] [RFC PATCH] libxl: add tunnelled migration support

[Joao Martins]

On 10/26/2016 07:33 AM, Bob Liu wrote:
> Tunnelled migration doesn't require any extra network connections beside the
> libvirt daemon.
> It's capable of strong encryption and is the default option in openstack-nova.
> 
> This patch add the tunnelled migration(Tunnel3params) support to libxl.
> The data flow in the src side is:
>  * libxlDoMigrateSend() -> pipe
>  * libxlTunnel3MigrationFunc() poll pipe out and then write to dest stream.
> 
> While in the dest side:
> Stream -> pipe -> 'recvfd of libxlDomainStartRestore'
> 
> The usage is the same as p2p migration, execpt adding one more '--tunnelled' 
> to
  ^^ except
> the libvirt p2p migration command.
> 
> Signed-off-by: Bob Liu 
Nice :) Now openstack no longer needs to have tunnelled flag removed on nova to
get migration working.

See some comments below, its a first review as I would still like to test it.

> ---
>  src/libxl/libxl_driver.c|  58 ++-
>  src/libxl/libxl_migration.c | 241 
> +---
>  src/libxl/libxl_migration.h |   9 ++
>  3 files changed, 292 insertions(+), 16 deletions(-)
> 
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index b66cb1f..a01bbff 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -5918,6 +5918,61 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
>  }
>  
>  static int
> +libxlDomainMigratePrepareTunnel3Params(virConnectPtr dconn,
> +   virStreamPtr st,
> +   virTypedParameterPtr params,
> +   int nparams,
> +   const char *cookiein,
> +   int cookieinlen,
> +   char **cookieout ATTRIBUTE_UNUSED,
> +   int *cookieoutlen ATTRIBUTE_UNUSED,
> +   unsigned int flags)
> +{
> +libxlDriverPrivatePtr driver = dconn->privateData;
> +virDomainDefPtr def = NULL;
> +const char *dom_xml = NULL;
> +const char *dname = NULL;
> +const char *uri_in = NULL;
> +
> +#ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
> +virReportUnsupportedError();
> +return -1;
> +#endif
> +
> +virCheckFlags(LIBXL_MIGRATION_FLAGS, -1);
> +if (virTypedParamsValidate(params, nparams, LIBXL_MIGRATION_PARAMETERS) 
> < 0)
> +goto error;
> +
> +if (virTypedParamsGetString(params, nparams,
> +VIR_MIGRATE_PARAM_DEST_XML,
> +_xml) < 0 ||
> +virTypedParamsGetString(params, nparams,
> +VIR_MIGRATE_PARAM_DEST_NAME,
> +) < 0 ||
> +virTypedParamsGetString(params, nparams,
> +VIR_MIGRATE_PARAM_URI,
> +_in) < 0)
> +
> +goto error;
> +
> +if (!(def = libxlDomainMigrationPrepareDef(driver, dom_xml, dname)))
> +goto error;
> +
> +if (virDomainMigratePrepareTunnel3ParamsEnsureACL(dconn, def) < 0)
> +goto error;
> +
> +if (libxlDomainMigrationPrepareTunnel3(dconn, st, , cookiein,
> +   cookieinlen, flags) < 0)
> +goto error;
> +
> +return 0;
> +
> + error:
> +virDomainDefFree(def);
> +return -1;
> +}
> +
> +static int
>  libxlDomainMigratePrepare3Params(virConnectPtr dconn,
>   virTypedParameterPtr params,
>   int nparams,
> @@ -6017,7 +6072,7 @@ libxlDomainMigratePerform3Params(virDomainPtr dom,
>  if (virDomainMigratePerform3ParamsEnsureACL(dom->conn, vm->def) < 0)
>  goto cleanup;
>  
> -if (flags & VIR_MIGRATE_PEER2PEER) {
> +if ((flags & (VIR_MIGRATE_TUNNELLED | VIR_MIGRATE_PEER2PEER))) {
>  if (libxlDomainMigrationPerformP2P(driver, vm, dom->conn, dom_xml,
> dconnuri, uri, dname, flags) < 0)
>  goto cleanup;
> @@ -6501,6 +6556,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
>  .nodeDeviceReset = libxlNodeDeviceReset, /* 1.2.3 */
>  .domainMigrateBegin3Params = libxlDomainMigrateBegin3Params, /* 1.2.6 */
>  .domainMigratePrepare3Params = libxlDomainMigratePrepare3Params, /* 
> 1.2.6 */
> +.domainMigratePrepareTunnel3Params = 
> libxlDomainMigratePrepareTunnel3Params, /* 2.3.1 */
The version here is incorrect. It should be the next one to be tagged (after the
ongoing freeze). Which means 2.5.0. Note that the versioning used has changed a
bit: major number is incremented per year, minor per month and bugfix number for
-maint releases.

>  .domainMigratePerform3Params = libxlDomainMigratePerform3Params, /* 
> 1.2.6 */
>  .domainMigrateFinish3Params = libxlDomainMigrateFinish3Params, /* 1.2.6 
> */
>  

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

[Joao Martins]

On 09/27/2016 05:05 AM, Jim Fehlig wrote:
> On 09/26/2016 11:33 AM, 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 <joao.m.mart...@oracle.com>
>> ---
>> Changes since v2:
>>  * Add relevant documentation about target type xen.
>> ---
>>  docs/formatdomain.html.in | 10 ++
>>  docs/schemas/domaincommon.rng | 11 +++
>>  src/conf/domain_conf.c| 18 ++
>>  src/conf/domain_conf.h|  1 +
>>  src/qemu/qemu_command.c   |  1 +
>>  5 files changed, 37 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
>> index f48a4d8..129ba62 100644
>> --- a/docs/formatdomain.html.in
>> +++ b/docs/formatdomain.html.in
>> @@ -5980,6 +5980,16 @@ qemu-kvm -net nic,model=? /dev/null
>>  Possible values for the state attribute are
>>  connected and disconnected.
>>
>> +  xen
>> +   Paravirtualized xen channel. Channel is exposed in the guest as a
>> +xen console but identified with a name. The setup of the channel
>> +depends to guest own rules and can live in a arbitrary path (for 
>> more
>> +info, please see > href="http://xenbits.xen.org/docs/unstable/misc/channel.txt;>http://xenbits.xen.org/docs/unstable/misc/channel.txt).
> 
> The last sentence is not clear IMO and I'd like to improve it before pushing
> this series. What do you think of the below diff? Or feel free to propose
> something better :-).
Much cleared indeed, it looks good to me. Specially the changes to the first
sentences.. I was sort of searching for that kind of working when making that 
text.

Joao

> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 129ba62..7008005 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -5981,12 +5981,12 @@ qemu-kvm -net nic,model=? /dev/null
>  connected and disconnected.
>
>xen
> -   Paravirtualized xen channel. Channel is exposed in the guest as a
> -xen console but identified with a name. The setup of the channel
> -depends to guest own rules and can live in a arbitrary path (for more
> -info, please see  href="http://xenbits.xen.org/docs/unstable/misc/channel.txt;>http://xenbits.xen.org/docs/unstable/misc/channel.txt).
> +   Paravirtualized Xen channel. Channel is exposed in the guest as a
> +Xen console but identified with a name. Setup and consumption of a 
> Xen
> +channel depends on software and configuration in the guest
> +(for more info, please see  href="http://xenbits.xen.org/docs/unstable/misc/channel.txt;>http://xenbits.xen.org/docs/unstable/misc/channel.txt).
>  Channel source path semantics are the same as the virtio target type.
> -Although state attribute is not provided as xen channels
> +The state attribute is not supported since Xen channels
>  lack the necessary probing mechanism.
>  Since 2.3.0
>
> 
> 
> Regards,
> Jim
> 

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

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

[Joao Martins]

On 09/26/2016 10:44 PM, Jim Fehlig wrote:
> On 09/26/2016 11:33 AM, 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. On socket case,
>> we autogenerate a path if not specified in the XML. Path autogenerated
>> is slightly different from qemu driver: qemu stores also on
>> "channels/target" but it creates then a directory per domain with
>> each channel target name. libxl doesn't appear to have a clear
>> definition of private files associated with each domain, so for
>> simplicity we do it slightly different. On qemu each autogenerated
>> channel goes like:
>>
>> channels/target//
>>
>> Whereas for libxl:
>>
>> channels/target/-
>>
>> Should note that if path is not specified it won't persist,
>> existing only on live XML, unless user had initially specified it.
>> 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 <joao.m.mart...@oracle.com>
>> ---
>> Since v2:
>>  * Remove ret variable and do similar to other make functions.
>>  * Have channelDir passed as an argument instead of driver.
>>
>> Since v1:
>>  * Autogenerated paths, and updated commit message explaning it the different
>> naming. Despite per domain name being slightly different, parent
>> directory is same across both drivers.
>> ---
>>  src/libxl/libxl_conf.c   | 110 
>> +++
>>  src/libxl/libxl_conf.h   |   3 ++
>>  src/libxl/libxl_domain.c |  43 +-
>>  src/libxl/libxl_driver.c |   7 +++
>>  4 files changed, 162 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>> index 92faa44..4c94d54 100644
>> --- a/src/libxl/libxl_conf.c
>> +++ b/src/libxl/libxl_conf.c
>> @@ -88,6 +88,7 @@ libxlDriverConfigDispose(void *obj)
>>  VIR_FREE(cfg->saveDir);
>>  VIR_FREE(cfg->autoDumpDir);
>>  VIR_FREE(cfg->lockManagerName);
>> +VIR_FREE(cfg->channelDir);
>>  virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares);
>>  }
>>  
>> @@ -1348,6 +1349,8 @@ libxlDriverConfigNew(void)
>>  goto error;
>>  if (VIR_STRDUP(cfg->autoDumpDir, LIBXL_DUMP_DIR) < 0)
>>  goto error;
>> +if (VIR_STRDUP(cfg->channelDir, LIBXL_CHANNEL_DIR) < 0)
>> +goto error;
>>  
>>  if (virAsprintf(_file, "%s/libxl-driver.log", cfg->logDir) < 0)
>>  goto error;
>> @@ -1499,6 +1502,107 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr 
>> cfg,
>>  
>>  }
>>  
>> +#ifdef LIBXL_HAVE_DEVICE_CHANNEL
>> +static int
>> +libxlPrepareChannel(virDomainChrDefPtr channel,
>> +const char *channelDir,
>> +const char *domainName)
>> +{
>> +if (channel->targetType == VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN &&
>> +channel->source.type == VIR_DOMAIN_CHR_TYPE_UNIX &&
>> +!channel->sourc

[libvirt] [PATCH v3 4/4] xlconfigtest: add test for channel conversion

[Joao Martins]

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
Acked-by: Jim Fehlig <jfeh...@suse.com>
---
 tests/xlconfigdata/test-channel-pty.cfg  | 13 
 tests/xlconfigdata/test-channel-pty.xml  | 33 +++
 tests/xlconfigdata/test-channel-unix.cfg | 13 
 tests/xlconfigdata/test-channel-unix.xml | 34 
 tests/xlconfigtest.c |  4 
 5 files changed, 97 insertions(+)
 create mode 100644 tests/xlconfigdata/test-channel-pty.cfg
 create mode 100644 tests/xlconfigdata/test-channel-pty.xml
 create mode 100644 tests/xlconfigdata/test-channel-unix.cfg
 create mode 100644 tests/xlconfigdata/test-channel-unix.xml

diff --git a/tests/xlconfigdata/test-channel-pty.cfg 
b/tests/xlconfigdata/test-channel-pty.cfg
new file mode 100644
index 000..b20e487
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-pty.cfg
@@ -0,0 +1,13 @@
+name = "XenGuest1"
+uuid = "45b60f51-88a9-47a8-a3b3-5e66d71b2283"
+maxmem = 512
+memory = 512
+vcpus = 1
+localtime = 0
+on_poweroff = "preserve"
+on_reboot = "restart"
+on_crash = "preserve"
+vif = [ "mac=5a:36:0e:be:00:09" ]
+bootloader = "/usr/bin/pygrub"
+disk = [ 
"format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/var/lib/xen/images/debian/disk.qcow2"
 ]
+channel = [ "connection=pty,name=org.qemu.guest_agent.0" ]
diff --git a/tests/xlconfigdata/test-channel-pty.xml 
b/tests/xlconfigdata/test-channel-pty.xml
new file mode 100644
index 000..17d0c67
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-pty.xml
@@ -0,0 +1,33 @@
+
+  XenGuest1
+  45b60f51-88a9-47a8-a3b3-5e66d71b2283
+  524288
+  524288
+  1
+  /usr/bin/pygrub
+  
+linux
+  
+  
+  preserve
+  restart
+  preserve
+  
+
+  
+  
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+
+  
+
diff --git a/tests/xlconfigdata/test-channel-unix.cfg 
b/tests/xlconfigdata/test-channel-unix.cfg
new file mode 100644
index 000..ada7001
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-unix.cfg
@@ -0,0 +1,13 @@
+name = "XenGuest1"
+uuid = "45b60f51-88a9-47a8-a3b3-5e66d71b2283"
+maxmem = 512
+memory = 512
+vcpus = 1
+localtime = 0
+on_poweroff = "preserve"
+on_reboot = "restart"
+on_crash = "preserve"
+vif = [ "mac=5a:36:0e:be:00:09" ]
+bootloader = "/usr/bin/pygrub"
+disk = [ 
"format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/var/lib/xen/images/debian/disk.qcow2"
 ]
+channel = [ 
"connection=socket,path=/path/to/socket,name=org.qemu.guest_agent.0" ]
diff --git a/tests/xlconfigdata/test-channel-unix.xml 
b/tests/xlconfigdata/test-channel-unix.xml
new file mode 100644
index 000..8f4eaa2
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-unix.xml
@@ -0,0 +1,34 @@
+
+  XenGuest1
+  45b60f51-88a9-47a8-a3b3-5e66d71b2283
+  524288
+  524288
+  1
+  /usr/bin/pygrub
+  
+linux
+  
+  
+  preserve
+  restart
+  preserve
+  
+
+  
+  
+  
+
+
+  
+
+
+  
+
+
+  
+  
+
+
+
+  
+
diff --git a/tests/xlconfigtest.c b/tests/xlconfigtest.c
index d99f887..31892da 100644
--- a/tests/xlconfigtest.c
+++ b/tests/xlconfigtest.c
@@ -268,6 +268,10 @@ mymain(void)
 DO_TEST_FORMAT("paravirt-cmdline-bogus-extra-root", false);
 DO_TEST("rbd-multihost-noauth");
 
+#ifdef LIBXL_HAVE_DEVICE_CHANNEL
+DO_TEST("channel-pty");
+DO_TEST("channel-unix");
+#endif
 #ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST
 DO_TEST("fullvirt-multiserial");
 #endif
-- 
2.1.4

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

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

[Joao Martins]

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 <joao.m.mart...@oracle.com>
---
Changes since v2:
 * Add relevant documentation about target type xen.
---
 docs/formatdomain.html.in | 10 ++
 docs/schemas/domaincommon.rng | 11 +++
 src/conf/domain_conf.c| 18 ++
 src/conf/domain_conf.h|  1 +
 src/qemu/qemu_command.c   |  1 +
 5 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index f48a4d8..129ba62 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -5980,6 +5980,16 @@ qemu-kvm -net nic,model=? /dev/null
 Possible values for the state attribute are
 connected and disconnected.
   
+  xen
+   Paravirtualized xen channel. Channel is exposed in the guest as a
+xen console but identified with a name. The setup of the channel
+depends to guest own rules and can live in a arbitrary path (for more
+info, please see http://xenbits.xen.org/docs/unstable/misc/channel.txt;>http://xenbits.xen.org/docs/unstable/misc/channel.txt).
+Channel source path semantics are the same as the virtio target type.
+Although state attribute is not provided as xen channels
+lack the necessary probing mechanism.
+Since 2.3.0
+  
   spicevmc
   Paravirtualized SPICE channel. The domain must also have a
 SPICE server as a graphics
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 95c7882..6eeb4e9 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3690,6 +3690,16 @@
   
 
   
+  
+
+  
+xen
+  
+  
+
+  
+
+  
   
 
   
@@ -3698,6 +3708,7 @@
 
   
   
+  
 
 
   
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index a06da46..7972a4e 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;
@@ -9923,10 +9925,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;
 
@@ -10217,7 +10221,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;
@@ -14417,6 +14422,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;
@@ -18434,6 +18440,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,
@@ -21556,11 

[libvirt] [PATCH v3 0/4] libxl: channels support

[Joao Martins]

Hey,

This v3 from channel series with latest comments addressed. Difference to
qemu driver would be only the autogenerated path being slightly different.

Channels have been on xen toolstack since Xen 4.5 and this small series
adds support for it, including xenconfig conversion and appropriate tests.
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"}]}

Thanks,
Joao

Joao Martins (4):
  conf: add xen type for channels
  libxl: channels support
  xenconfig: channels conversion support
  xlconfigtest: add test for channel conversion

 docs/formatdomain.html.in|  10 ++
 docs/schemas/domaincommon.rng|  11 ++
 src/conf/domain_conf.c   |  18 +++-
 src/conf/domain_conf.h   |   1 +
 src/libxl/libxl_conf.c   | 110 +++
 src/libxl/libxl_conf.h   |   3 +
 src/libxl/libxl_domain.c |  43 +++-
 src/libxl/libxl_driver.c |   7 ++
 src/qemu/qemu_command.c  |   1 +
 src/xenconfig/xen_xl.c   | 176 +++
 tests/xlconfigdata/test-channel-pty.cfg  |  13 +++
 tests/xlconfigdata/test-channel-pty.xml  |  33 ++
 tests/xlconfigdata/test-channel-unix.cfg |  13 +++
 tests/xlconfigdata/test-channel-unix.xml |  34 ++
 tests/xlconfigtest.c |   4 +
 15 files changed, 472 insertions(+), 5 deletions(-)
 create mode 100644 tests/xlconfigdata/test-channel-pty.cfg
 create mode 100644 tests/xlconfigdata/test-channel-pty.xml
 create mode 100644 tests/xlconfigdata/test-channel-unix.cfg
 create mode 100644 tests/xlconfigdata/test-channel-unix.xml

-- 
2.1.4

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

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

[Joao Martins]

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 <joao.m.mart...@oracle.com>
Acked-by: Jim Fehlig <jfeh...@suse.com>
---
Changes since v1:
* Move path to UNIX case.
---
 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 4615bfd..a06983e 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, NULL) < 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:
+virBufferAddLit(, "socket,");
+/* path */
+if (channel->source.data.nix.path)
+virBufferAsprintf(, "path=%s,",
+  channel-

[libvirt] [PATCH v3 2/4] libxl: channels support

[Joao Martins]

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. On socket case,
we autogenerate a path if not specified in the XML. Path autogenerated
is slightly different from qemu driver: qemu stores also on
"channels/target" but it creates then a directory per domain with
each channel target name. libxl doesn't appear to have a clear
definition of private files associated with each domain, so for
simplicity we do it slightly different. On qemu each autogenerated
channel goes like:

channels/target//

Whereas for libxl:

channels/target/-

Should note that if path is not specified it won't persist,
existing only on live XML, unless user had initially specified it.
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 <joao.m.mart...@oracle.com>
---
Since v2:
 * Remove ret variable and do similar to other make functions.
 * Have channelDir passed as an argument instead of driver.

Since v1:
 * Autogenerated paths, and updated commit message explaning it the different
naming. Despite per domain name being slightly different, parent
directory is same across both drivers.
---
 src/libxl/libxl_conf.c   | 110 +++
 src/libxl/libxl_conf.h   |   3 ++
 src/libxl/libxl_domain.c |  43 +-
 src/libxl/libxl_driver.c |   7 +++
 4 files changed, 162 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 92faa44..4c94d54 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -88,6 +88,7 @@ libxlDriverConfigDispose(void *obj)
 VIR_FREE(cfg->saveDir);
 VIR_FREE(cfg->autoDumpDir);
 VIR_FREE(cfg->lockManagerName);
+VIR_FREE(cfg->channelDir);
 virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares);
 }
 
@@ -1348,6 +1349,8 @@ libxlDriverConfigNew(void)
 goto error;
 if (VIR_STRDUP(cfg->autoDumpDir, LIBXL_DUMP_DIR) < 0)
 goto error;
+if (VIR_STRDUP(cfg->channelDir, LIBXL_CHANNEL_DIR) < 0)
+goto error;
 
 if (virAsprintf(_file, "%s/libxl-driver.log", cfg->logDir) < 0)
 goto error;
@@ -1499,6 +1502,107 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
 
 }
 
+#ifdef LIBXL_HAVE_DEVICE_CHANNEL
+static int
+libxlPrepareChannel(virDomainChrDefPtr channel,
+const char *channelDir,
+const char *domainName)
+{
+if (channel->targetType == VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN &&
+channel->source.type == VIR_DOMAIN_CHR_TYPE_UNIX &&
+!channel->source.data.nix.path) {
+if (virAsprintf(>source.data.nix.path,
+"%s/%s-%s", channelDir, domainName,
+channel->target.name ? channel->target.name
+: "unknown.sock") < 0)
+return -1;
+
+channel->source.data.nix.listen = true;
+}
+
+return 0;
+}
+
+static int
+libxlMakeChannel(virDomainChrDefPtr l_channel,
+ libxl_device_channel *x_channel)
+{
+libxl_device_channel_init(x_channel);
+
+if (l_channel->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("channel target type not supported"));
+return -1;
+}
+
+switch (l_channel->source.type) {
+case VIR_DOMAIN_CHR_TYPE_PTY:
+x_channel->connection = LIBXL_CHANNEL_CONNECTION_PTY;
+break;
+case VIR_DOMAI

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

[Joao Martins]

On 09/26/2016 05:27 PM, Jim Fehlig wrote:
> On 09/26/2016 09:30 AM, Joao Martins wrote:
>> On 09/26/2016 03:21 PM, Jim Fehlig wrote:
>>> On 09/25/2016 01:13 PM, Joao Martins wrote:
>>>> On 09/25/2016 07:55 PM, Joao Martins wrote:
>>>>> On 09/24/2016 12:15 AM, Joao Martins wrote:
>>>>>> On September 23, 2016 11:12:00 PM GMT+01:00, Jim Fehlig 
>>>>>> <jfeh...@suse.com> wrote:
>>>>>>> On 09/22/2016 01:53 PM, Joao Martins wrote:
>>>>>>>> [snip]
>>>>>>>>  int
>>>>>>>> -libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
>>>>>>>> +libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
>>>>>>>> virDomainDefPtr def,
>>>>>>>> libxl_ctx *ctx,
>>>>>>>> libxl_domain_config *d_config)
>>>>>>>>  {
>>>>>>>> +virPortAllocatorPtr graphicsports =
>>>>>>> driver->reservedGraphicsPorts;
>>>>>>>> +
>>>>>>> Spurious change?
>>>>>> This (and the other two below) was intended, as I needed
>>>>>>  channelDir. and instead of having yet another argument, I
>>>>>>  passed driver instead as graphics port was using it too.
>>>>>>
>>>>>> But I could use the macro directly, or add another argument if you 
>>>>>> prefer.
>>>>> Hmm, I can just avoid passing driver and have cfg->channelDir added as an
>>>>> argument. I just noticed that I am unnecessarily doing 
>>>>> libxlDriverConfigGet
>>>>> twice and perhaps if a third argument is added in the future then probably
>>>>> consider having driver be passed as an argument?
>>>> Or even better have cfg as the function argument instead to allow also 
>>>> removing
>>>> "ctx" argument. Both channelDir and ctx are stored in cfg. This way we 
>>>> reduce
>>>> the number of arguments plus allow future usage on other functions called 
>>>> from
>>>> libxlBuildDomainConfig.
>>> Yep, I think that is fine. We primarily want to avoid making
>>> libxlBuildDomainConfig difficult to call from the unit tests. I realize we 
>>> don't
>>> currently do that, but the eventual plan is to test the conversion of
>>> virDomainDef to libxl_domain_config. danpb did some initial work on that 
>>> quite
>>> some time ago, see commit 5da28f24.
>> Ah nice to know, I wasn't aware of that work. This cover letter
>> (https://www.redhat.com/archives/libvir-list/2014-May/msg01102.html) 
>> explains it
>> all too.
> 
> Some of those patches were pushed. I did some followup work
> 
> https://www.redhat.com/archives/libvir-list/2014-September/msg00180.html
> 
> which also resulted in some patches being pushed. But the meaty parts of the
> series that actually provide the conversion tests were never committed. The 
> last
> attempt to revive the work also stalled
> 
>  https://www.redhat.com/archives/libvir-list/2015-January/msg00924.html
> 


> Thinking about it again, I seems the best way forward is something along the
> lines of option 3 described in that thread
> 
> "make use of new functionality in Xen 4.5 such as
> libxl_domain_config_from_json() and libxl_domain_config_compare()"
Interesting, the latter though (libxl_domain_config_compare) doesn't appear to
be implemented on 4.7 (or upcoming 4.8) and sounds like even if implemented that
it would rule out most of the versions :( Probably worked out with a shim for
older versions that implement equivalent of libxl_domain_config_compare().

>>  What I am in this patch is clearly opposite the effort of commit
>> 5da28f24 and a6abdbf. But now I am not sure if what I proposed in my earlier
>> paragrah is any different: we can probably get away with a mock of
>> libxlDriverConfig but not sure.
> 
> I suppose mocking it would be easier if libxl_ctx_alloc supported a dummy 
> mode.
> I.e. if this bug was fixed
> 
> https://bugs.xenproject.org/xen/bug/41
> 
>>  In the end sounds like just adding channelDir to
>> the function arguments might end up being better?
> 
> IMO that is probably the best approach until we have the conversion tests
> figured out.
Cool, thanks for the feedback! Let me submit v3 with these fixed.

> 
> BTW, can channels be hot (un)plugged? If so, it's another argument for just
> passing the channelDir. Future external callers of libxlMakeChannel() would 
> have
> access to the libxlDriverConfig object, and hence channelDir.
AFAICT there's no API for hotplugging channels, very much like serials/consoles
can't be too hotplugged.

Joao

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

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

[Joao Martins]

On 09/26/2016 03:21 PM, Jim Fehlig wrote:
> On 09/25/2016 01:13 PM, Joao Martins wrote:
>> On 09/25/2016 07:55 PM, Joao Martins wrote:
>>> On 09/24/2016 12:15 AM, Joao Martins wrote:
>>>> On September 23, 2016 11:12:00 PM GMT+01:00, Jim Fehlig <jfeh...@suse.com> 
>>>> wrote:
>>>>> On 09/22/2016 01:53 PM, Joao Martins wrote:
>>>>>> [snip]
>>>>>>  int
>>>>>> -libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
>>>>>> +libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
>>>>>> virDomainDefPtr def,
>>>>>> libxl_ctx *ctx,
>>>>>> libxl_domain_config *d_config)
>>>>>>  {
>>>>>> +virPortAllocatorPtr graphicsports =
>>>>> driver->reservedGraphicsPorts;
>>>>>> +
>>>>> Spurious change?
>>>> This (and the other two below) was intended, as I needed
>>>>  channelDir. and instead of having yet another argument, I
>>>>  passed driver instead as graphics port was using it too.
>>>>
>>>> But I could use the macro directly, or add another argument if you prefer.
>>> Hmm, I can just avoid passing driver and have cfg->channelDir added as an
>>> argument. I just noticed that I am unnecessarily doing libxlDriverConfigGet
>>> twice and perhaps if a third argument is added in the future then probably
>>> consider having driver be passed as an argument?
>> Or even better have cfg as the function argument instead to allow also 
>> removing
>> "ctx" argument. Both channelDir and ctx are stored in cfg. This way we reduce
>> the number of arguments plus allow future usage on other functions called 
>> from
>> libxlBuildDomainConfig.
> 
> Yep, I think that is fine. We primarily want to avoid making
> libxlBuildDomainConfig difficult to call from the unit tests. I realize we 
> don't
> currently do that, but the eventual plan is to test the conversion of
> virDomainDef to libxl_domain_config. danpb did some initial work on that quite
> some time ago, see commit 5da28f24.

Ah nice to know, I wasn't aware of that work. This cover letter
(https://www.redhat.com/archives/libvir-list/2014-May/msg01102.html) explains it
all too. What I am in this patch is clearly opposite the effort of commit
5da28f24 and a6abdbf. But now I am not sure if what I proposed in my earlier
paragrah is any different: we can probably get away with a mock of
libxlDriverConfig but not sure. In the end sounds like just adding channelDir to
the function arguments might end up being better?

Joao

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

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

[Joao Martins]

On 09/25/2016 07:55 PM, Joao Martins wrote:
> On 09/24/2016 12:15 AM, Joao Martins wrote:
>> On September 23, 2016 11:12:00 PM GMT+01:00, Jim Fehlig <jfeh...@suse.com> 
>> wrote:
>>> On 09/22/2016 01:53 PM, Joao Martins wrote:
>>>> [snip]
>>>>  int
>>>> -libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
>>>> +libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
>>>> virDomainDefPtr def,
>>>> libxl_ctx *ctx,
>>>> libxl_domain_config *d_config)
>>>>  {
>>>> +virPortAllocatorPtr graphicsports =
>>> driver->reservedGraphicsPorts;
>>>> +
>>>
>>> Spurious change?
>>
>> This (and the other two below) was intended, as I needed
>>  channelDir. and instead of having yet another argument, I
>>  passed driver instead as graphics port was using it too.
>>
>> But I could use the macro directly, or add another argument if you prefer.
> 
> Hmm, I can just avoid passing driver and have cfg->channelDir added as an
> argument. I just noticed that I am unnecessarily doing libxlDriverConfigGet
> twice and perhaps if a third argument is added in the future then probably
> consider having driver be passed as an argument?
Or even better have cfg as the function argument instead to allow also removing
"ctx" argument. Both channelDir and ctx are stored in cfg. This way we reduce
the number of arguments plus allow future usage on other functions called from
libxlBuildDomainConfig.

Joao

P.S Sorry for so many messages!

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

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

[Joao Martins]

On 09/24/2016 12:15 AM, Joao Martins wrote:
> On September 23, 2016 11:12:00 PM GMT+01:00, Jim Fehlig <jfeh...@suse.com> 
> wrote:
>> On 09/22/2016 01:53 PM, Joao Martins wrote:
>>> 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. On socket case,
>>> we autogenerate a path if not specified in the XML. Path
>> autogenerated
>>> is slightly different from qemu driver: qemu stores also on
>>> "channels/target" but it creates then a directory per domain with
>>> each channel target name. libxl doesn't appear to have a clear
>>> definition of private files associated with each domain, so for
>>> simplicity we do it slightly different. On qemu each autogenerated
>>> channel goes like:
>>>
>>> channels/target//
>>>
>>> Whereas for libxl:
>>>
>>> channels/target/-
>>>
>>> Should note that if path is not specified it won't persist,
>>> existing only on live XML, unless user had initially specified it.
>>> 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 <joao.m.mart...@oracle.com>
>>> ---
>>> Since v1:
>>> * Autogenerated paths, and updated commit message explaning it the
>> different
>>> naming. Despite per domain name being slightly different, parent
>>> directory is same across both drivers.
>>> * Remove the switch case from target type xen and rework the function
>> structure
>>> a bit.
>>> ---
>>>  src/libxl/libxl_conf.c   | 120
>> ++-
>>>  src/libxl/libxl_conf.h   |   4 +-
>>>  src/libxl/libxl_domain.c |  44 -
>>>  src/libxl/libxl_driver.c |   7 +++
>>>  4 files changed, 171 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index 306e441..824f2d2 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -88,6 +88,7 @@ libxlDriverConfigDispose(void *obj)
>>>  VIR_FREE(cfg->saveDir);
>>>  VIR_FREE(cfg->autoDumpDir);
>>>  VIR_FREE(cfg->lockManagerName);
>>> +VIR_FREE(cfg->channelDir);
>>>  virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares);
>>>  }
>>>  
>>> @@ -1339,6 +1340,8 @@ libxlDriverConfigNew(void)
>>>  goto error;
>>>  if (VIR_STRDUP(cfg->autoDumpDir, LIBXL_DUMP_DIR) < 0)
>>>  goto error;
>>> +if (VIR_STRDUP(cfg->channelDir, LIBXL_CHANNEL_DIR) < 0)
>>> +goto error;
>>>  
>>>  if (virAsprintf(_file, "%s/libxl-driver.log", cfg->logDir) <
>> 0)
>>>  goto error;
>>> @@ -1490,6 +1493,114 @@ int
>> libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
>>>  
>>>  }
>>>  
>>> +#ifdef LIB

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

[Joao Martins]

On 09/24/2016 12:04 AM, Joao Martins wrote:
> On September 23, 2016 11:05:57 PM GMT+01:00, Jim Fehlig <jfeh...@suse.com> 
> wrote:
>> On 09/22/2016 01:53 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 <joao.m.mart...@oracle.com>
>>> ---
>>>  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 95c7882..6eeb4e9 100644
>>> --- a/docs/schemas/domaincommon.rng
>>> +++ b/docs/schemas/domaincommon.rng
>>> @@ -3690,6 +3690,16 @@
>>>
>>>  
>>>
>>> +  
>>> +
>>> +  
>>> +xen
>>> +  
>>> +  
>>> +
>>> +  
>>> +
>>> +  
>>>
>>>  
>>>
>>> @@ -3698,6 +3708,7 @@
>>>  
>>>
>>>
>>> +  
>>>  
>>>  
>>>
>>
>> Sorry for not mentioning this while reviewing V1, but changes to the
>> domain
>> schema typically need a corresponding change to docs/formatdomain.html.
>> I think
>> it behooves us to mention the Xen support in the 'channels' section of
>> that page.
> 
> Ah good point, let me add it to v3. I will
>  send it before the freeze.
I'll adding this to the docs:

  xen
   Paravirtualized xen channel. Channel is exposed in the guest as a
   xen console but identified with a name. The setup of the channel
   depends to guest own rules and can live in a arbitrary path (for more
   info, please see http://xenbits.xen.org/docs/unstable/misc/channel.txt;>http://xenbits.xen.org/docs/unstable/misc/channel.txt).
   Channel source path semantics are the same as the virtio target type.
   Although state attribute is not provided as xen channels
   lack the necessary probing mechanism.
Since 2.3.0
  

Joao

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

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

[Joao Martins]

On September 23, 2016 11:12:00 PM GMT+01:00, Jim Fehlig <jfeh...@suse.com> 
wrote:
>On 09/22/2016 01:53 PM, Joao Martins wrote:
>> 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. On socket case,
>> we autogenerate a path if not specified in the XML. Path
>autogenerated
>> is slightly different from qemu driver: qemu stores also on
>> "channels/target" but it creates then a directory per domain with
>> each channel target name. libxl doesn't appear to have a clear
>> definition of private files associated with each domain, so for
>> simplicity we do it slightly different. On qemu each autogenerated
>> channel goes like:
>>
>> channels/target//
>>
>> Whereas for libxl:
>>
>> channels/target/-
>>
>> Should note that if path is not specified it won't persist,
>> existing only on live XML, unless user had initially specified it.
>> 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 <joao.m.mart...@oracle.com>
>> ---
>> Since v1:
>> * Autogenerated paths, and updated commit message explaning it the
>different
>> naming. Despite per domain name being slightly different, parent
>> directory is same across both drivers.
>> * Remove the switch case from target type xen and rework the function
>structure
>> a bit.
>> ---
>>  src/libxl/libxl_conf.c   | 120
>++-
>>  src/libxl/libxl_conf.h   |   4 +-
>>  src/libxl/libxl_domain.c |  44 -
>>  src/libxl/libxl_driver.c |   7 +++
>>  4 files changed, 171 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>> index 306e441..824f2d2 100644
>> --- a/src/libxl/libxl_conf.c
>> +++ b/src/libxl/libxl_conf.c
>> @@ -88,6 +88,7 @@ libxlDriverConfigDispose(void *obj)
>>  VIR_FREE(cfg->saveDir);
>>  VIR_FREE(cfg->autoDumpDir);
>>  VIR_FREE(cfg->lockManagerName);
>> +VIR_FREE(cfg->channelDir);
>>  virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares);
>>  }
>>  
>> @@ -1339,6 +1340,8 @@ libxlDriverConfigNew(void)
>>  goto error;
>>  if (VIR_STRDUP(cfg->autoDumpDir, LIBXL_DUMP_DIR) < 0)
>>  goto error;
>> +if (VIR_STRDUP(cfg->channelDir, LIBXL_CHANNEL_DIR) < 0)
>> +goto error;
>>  
>>  if (virAsprintf(_file, "%s/libxl-driver.log", cfg->logDir) <
>0)
>>  goto error;
>> @@ -1490,6 +1493,114 @@ int
>libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
>>  
>>  }
>>  
>> +#ifdef LIBXL_HAVE_DEVICE_CHANNEL
>> +static int
>> +libxlPrepareChannel(virDomainChrDefPtr channel,
>> +const char *channelDir,
>> +const char *domainName)
>> +{
>> +if (channel->targetType ==
>VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN &&
>> +channel->source.type == VIR_DOMAIN_CHR_TYPE_UNIX &&
>> +!channel->source.data.nix.path) {

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

[Joao Martins]

On September 23, 2016 11:05:57 PM GMT+01:00, Jim Fehlig <jfeh...@suse.com> 
wrote:
>On 09/22/2016 01:53 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 <joao.m.mart...@oracle.com>
>> ---
>>  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 95c7882..6eeb4e9 100644
>> --- a/docs/schemas/domaincommon.rng
>> +++ b/docs/schemas/domaincommon.rng
>> @@ -3690,6 +3690,16 @@
>>
>>  
>>
>> +  
>> +
>> +  
>> +xen
>> +  
>> +  
>> +
>> +  
>> +
>> +  
>>
>>  
>>
>> @@ -3698,6 +3708,7 @@
>>  
>>
>>
>> +  
>>  
>>  
>>
>
>Sorry for not mentioning this while reviewing V1, but changes to the
>domain
>schema typically need a corresponding change to docs/formatdomain.html.
>I think
>it behooves us to mention the Xen support in the 'channels' section of
>that page.

Ah good point, let me add it to v3. I will
 send it before the freeze.

Joao


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

[libvirt] [PATCH v2 0/4] libxl: channels support

[Joao Martins]

Hey,

This v2 from channel series. Since v1 path is now autogenerated as needed,
and a few other comments from Jim that were addressed. Difference to qemu
driver would be only the autogenerated path being slightly different.

Channels have been on xen toolstack since Xen 4.5 and this small series
adds support for it, including xenconfig conversion and appropriate tests.
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"}]}

Thanks,
Joao


Joao Martins (4):
  conf: add xen type for channels
  libxl: channels support
  xenconfig: channels conversion support
  xlconfigtest: add test for channel conversion

 docs/schemas/domaincommon.rng|  11 ++
 src/conf/domain_conf.c   |  18 +++-
 src/conf/domain_conf.h   |   1 +
 src/libxl/libxl_conf.c   | 120 -
 src/libxl/libxl_conf.h   |   4 +-
 src/libxl/libxl_domain.c |  44 +++-
 src/libxl/libxl_driver.c |   7 ++
 src/qemu/qemu_command.c  |   1 +
 src/xenconfig/xen_xl.c   | 176 +++
 tests/xlconfigdata/test-channel-pty.cfg  |  13 +++
 tests/xlconfigdata/test-channel-pty.xml  |  33 ++
 tests/xlconfigdata/test-channel-unix.cfg |  13 +++
 tests/xlconfigdata/test-channel-unix.xml |  34 ++
 tests/xlconfigtest.c |   4 +
 14 files changed, 471 insertions(+), 8 deletions(-)
 create mode 100644 tests/xlconfigdata/test-channel-pty.cfg
 create mode 100644 tests/xlconfigdata/test-channel-pty.xml
 create mode 100644 tests/xlconfigdata/test-channel-unix.cfg
 create mode 100644 tests/xlconfigdata/test-channel-unix.xml

-- 
2.1.4

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

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

[Joao Martins]

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 <joao.m.mart...@oracle.com>
---
 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 95c7882..6eeb4e9 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3690,6 +3690,16 @@
   
 
   
+  
+
+  
+xen
+  
+  
+
+  
+
+  
   
 
   
@@ -3698,6 +3708,7 @@
 
   
   
+  
 
 
   
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 5fede3d..1b14efd 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;
@@ -9909,10 +9911,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;
 
@@ -10203,7 +10207,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;
@@ -14403,6 +14408,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;
@@ -18415,6 +18421,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,
@@ -21537,11 +21545,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'",
   
virDomainChrDeviceStateTypeToString(def->state));
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index d4a84c3..a0619f5 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1021,6 +1021,7 @@ typedef enum {
 VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_NONE = 0,
 VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_GUESTFWD,
 VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO,
+VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE

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

[Joao Martins]

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 <joao.m.mart...@oracle.com>
---
Changes since v1:
* Move path to UNIX case.
---
 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..0c02e1f 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:
+virBufferAddLit(, "socket,");
+/* path */
+if (channel->source.data.nix.path)
+virBufferAsprintf(, "path=%s,",
+  channel->source.data.nix.path);
+break;
+  

[libvirt] [PATCH v2 4/4] xlconfigtest: add test for channel conversion

[Joao Martins]

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 tests/xlconfigdata/test-channel-pty.cfg  | 13 
 tests/xlconfigdata/test-channel-pty.xml  | 33 +++
 tests/xlconfigdata/test-channel-unix.cfg | 13 
 tests/xlconfigdata/test-channel-unix.xml | 34 
 tests/xlconfigtest.c |  4 
 5 files changed, 97 insertions(+)
 create mode 100644 tests/xlconfigdata/test-channel-pty.cfg
 create mode 100644 tests/xlconfigdata/test-channel-pty.xml
 create mode 100644 tests/xlconfigdata/test-channel-unix.cfg
 create mode 100644 tests/xlconfigdata/test-channel-unix.xml

diff --git a/tests/xlconfigdata/test-channel-pty.cfg 
b/tests/xlconfigdata/test-channel-pty.cfg
new file mode 100644
index 000..b20e487
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-pty.cfg
@@ -0,0 +1,13 @@
+name = "XenGuest1"
+uuid = "45b60f51-88a9-47a8-a3b3-5e66d71b2283"
+maxmem = 512
+memory = 512
+vcpus = 1
+localtime = 0
+on_poweroff = "preserve"
+on_reboot = "restart"
+on_crash = "preserve"
+vif = [ "mac=5a:36:0e:be:00:09" ]
+bootloader = "/usr/bin/pygrub"
+disk = [ 
"format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/var/lib/xen/images/debian/disk.qcow2"
 ]
+channel = [ "connection=pty,name=org.qemu.guest_agent.0" ]
diff --git a/tests/xlconfigdata/test-channel-pty.xml 
b/tests/xlconfigdata/test-channel-pty.xml
new file mode 100644
index 000..17d0c67
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-pty.xml
@@ -0,0 +1,33 @@
+
+  XenGuest1
+  45b60f51-88a9-47a8-a3b3-5e66d71b2283
+  524288
+  524288
+  1
+  /usr/bin/pygrub
+  
+linux
+  
+  
+  preserve
+  restart
+  preserve
+  
+
+  
+  
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+
+  
+
diff --git a/tests/xlconfigdata/test-channel-unix.cfg 
b/tests/xlconfigdata/test-channel-unix.cfg
new file mode 100644
index 000..ada7001
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-unix.cfg
@@ -0,0 +1,13 @@
+name = "XenGuest1"
+uuid = "45b60f51-88a9-47a8-a3b3-5e66d71b2283"
+maxmem = 512
+memory = 512
+vcpus = 1
+localtime = 0
+on_poweroff = "preserve"
+on_reboot = "restart"
+on_crash = "preserve"
+vif = [ "mac=5a:36:0e:be:00:09" ]
+bootloader = "/usr/bin/pygrub"
+disk = [ 
"format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/var/lib/xen/images/debian/disk.qcow2"
 ]
+channel = [ 
"connection=socket,path=/path/to/socket,name=org.qemu.guest_agent.0" ]
diff --git a/tests/xlconfigdata/test-channel-unix.xml 
b/tests/xlconfigdata/test-channel-unix.xml
new file mode 100644
index 000..8f4eaa2
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-unix.xml
@@ -0,0 +1,34 @@
+
+  XenGuest1
+  45b60f51-88a9-47a8-a3b3-5e66d71b2283
+  524288
+  524288
+  1
+  /usr/bin/pygrub
+  
+linux
+  
+  
+  preserve
+  restart
+  preserve
+  
+
+  
+  
+  
+
+
+  
+
+
+  
+
+
+  
+  
+
+
+
+  
+
diff --git a/tests/xlconfigtest.c b/tests/xlconfigtest.c
index 61a6295..8fc73ee 100644
--- a/tests/xlconfigtest.c
+++ b/tests/xlconfigtest.c
@@ -268,6 +268,10 @@ mymain(void)
 DO_TEST_FORMAT("paravirt-cmdline-bogus-extra-root", false);
 DO_TEST("rbd-multihost-noauth");
 
+#ifdef LIBXL_HAVE_DEVICE_CHANNEL
+DO_TEST("channel-pty");
+DO_TEST("channel-unix");
+#endif
 #ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST
 DO_TEST("fullvirt-multiserial");
 #endif
-- 
2.1.4

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

[libvirt] [PATCH v2 2/4] libxl: channels support

[Joao Martins]

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. On socket case,
we autogenerate a path if not specified in the XML. Path autogenerated
is slightly different from qemu driver: qemu stores also on
"channels/target" but it creates then a directory per domain with
each channel target name. libxl doesn't appear to have a clear
definition of private files associated with each domain, so for
simplicity we do it slightly different. On qemu each autogenerated
channel goes like:

channels/target//

Whereas for libxl:

channels/target/-

Should note that if path is not specified it won't persist,
existing only on live XML, unless user had initially specified it.
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 <joao.m.mart...@oracle.com>
---
Since v1:
* Autogenerated paths, and updated commit message explaning it the different
naming. Despite per domain name being slightly different, parent
directory is same across both drivers.
* Remove the switch case from target type xen and rework the function structure
a bit.
---
 src/libxl/libxl_conf.c   | 120 ++-
 src/libxl/libxl_conf.h   |   4 +-
 src/libxl/libxl_domain.c |  44 -
 src/libxl/libxl_driver.c |   7 +++
 4 files changed, 171 insertions(+), 4 deletions(-)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 306e441..824f2d2 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -88,6 +88,7 @@ libxlDriverConfigDispose(void *obj)
 VIR_FREE(cfg->saveDir);
 VIR_FREE(cfg->autoDumpDir);
 VIR_FREE(cfg->lockManagerName);
+VIR_FREE(cfg->channelDir);
 virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares);
 }
 
@@ -1339,6 +1340,8 @@ libxlDriverConfigNew(void)
 goto error;
 if (VIR_STRDUP(cfg->autoDumpDir, LIBXL_DUMP_DIR) < 0)
 goto error;
+if (VIR_STRDUP(cfg->channelDir, LIBXL_CHANNEL_DIR) < 0)
+goto error;
 
 if (virAsprintf(_file, "%s/libxl-driver.log", cfg->logDir) < 0)
 goto error;
@@ -1490,6 +1493,114 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
 
 }
 
+#ifdef LIBXL_HAVE_DEVICE_CHANNEL
+static int
+libxlPrepareChannel(virDomainChrDefPtr channel,
+const char *channelDir,
+const char *domainName)
+{
+if (channel->targetType == VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN &&
+channel->source.type == VIR_DOMAIN_CHR_TYPE_UNIX &&
+!channel->source.data.nix.path) {
+if (virAsprintf(>source.data.nix.path,
+"%s/%s-%s", channelDir, domainName,
+channel->target.name ? channel->target.name
+: "unknown.sock") < 0)
+return -1;
+
+channel->source.data.nix.listen = true;
+}
+
+return 0;
+}
+
+static int
+libxlMakeChannel(virDomainChrDefPtr l_channel,
+ libxl_device_channel *x_channel)
+{
+int ret = -1;
+
+libxl_device_channel_init(x_channel);
+
+if (l_channel->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("channel target type not supported"));
+return ret;
+}
+
+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:
+   

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 <joao.m.mart...@oracle.com>
>> ---
>>  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_V

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 <joao.m.mart...@oracle.com>
>> ---
>>  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, 

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 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 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 <joao.m.mart...@oracle.com>
>> ---
>>
>> 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 cleare

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

[libvirt] [PATCH v1 4/4] xlconfigtest: add test for channel conversion

[Joao Martins]

Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
---
 tests/xlconfigdata/test-channel-pty.cfg  | 13 
 tests/xlconfigdata/test-channel-pty.xml  | 33 +++
 tests/xlconfigdata/test-channel-unix.cfg | 13 
 tests/xlconfigdata/test-channel-unix.xml | 34 
 tests/xlconfigtest.c |  4 
 5 files changed, 97 insertions(+)
 create mode 100644 tests/xlconfigdata/test-channel-pty.cfg
 create mode 100644 tests/xlconfigdata/test-channel-pty.xml
 create mode 100644 tests/xlconfigdata/test-channel-unix.cfg
 create mode 100644 tests/xlconfigdata/test-channel-unix.xml

diff --git a/tests/xlconfigdata/test-channel-pty.cfg 
b/tests/xlconfigdata/test-channel-pty.cfg
new file mode 100644
index 000..b20e487
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-pty.cfg
@@ -0,0 +1,13 @@
+name = "XenGuest1"
+uuid = "45b60f51-88a9-47a8-a3b3-5e66d71b2283"
+maxmem = 512
+memory = 512
+vcpus = 1
+localtime = 0
+on_poweroff = "preserve"
+on_reboot = "restart"
+on_crash = "preserve"
+vif = [ "mac=5a:36:0e:be:00:09" ]
+bootloader = "/usr/bin/pygrub"
+disk = [ 
"format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/var/lib/xen/images/debian/disk.qcow2"
 ]
+channel = [ "connection=pty,name=org.qemu.guest_agent.0" ]
diff --git a/tests/xlconfigdata/test-channel-pty.xml 
b/tests/xlconfigdata/test-channel-pty.xml
new file mode 100644
index 000..17d0c67
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-pty.xml
@@ -0,0 +1,33 @@
+
+  XenGuest1
+  45b60f51-88a9-47a8-a3b3-5e66d71b2283
+  524288
+  524288
+  1
+  /usr/bin/pygrub
+  
+linux
+  
+  
+  preserve
+  restart
+  preserve
+  
+
+  
+  
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+
+  
+
diff --git a/tests/xlconfigdata/test-channel-unix.cfg 
b/tests/xlconfigdata/test-channel-unix.cfg
new file mode 100644
index 000..ada7001
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-unix.cfg
@@ -0,0 +1,13 @@
+name = "XenGuest1"
+uuid = "45b60f51-88a9-47a8-a3b3-5e66d71b2283"
+maxmem = 512
+memory = 512
+vcpus = 1
+localtime = 0
+on_poweroff = "preserve"
+on_reboot = "restart"
+on_crash = "preserve"
+vif = [ "mac=5a:36:0e:be:00:09" ]
+bootloader = "/usr/bin/pygrub"
+disk = [ 
"format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/var/lib/xen/images/debian/disk.qcow2"
 ]
+channel = [ 
"connection=socket,path=/path/to/socket,name=org.qemu.guest_agent.0" ]
diff --git a/tests/xlconfigdata/test-channel-unix.xml 
b/tests/xlconfigdata/test-channel-unix.xml
new file mode 100644
index 000..8f4eaa2
--- /dev/null
+++ b/tests/xlconfigdata/test-channel-unix.xml
@@ -0,0 +1,34 @@
+
+  XenGuest1
+  45b60f51-88a9-47a8-a3b3-5e66d71b2283
+  524288
+  524288
+  1
+  /usr/bin/pygrub
+  
+linux
+  
+  
+  preserve
+  restart
+  preserve
+  
+
+  
+  
+  
+
+
+  
+
+
+  
+
+
+  
+  
+
+
+
+  
+
diff --git a/tests/xlconfigtest.c b/tests/xlconfigtest.c
index 61a6295..8fc73ee 100644
--- a/tests/xlconfigtest.c
+++ b/tests/xlconfigtest.c
@@ -268,6 +268,10 @@ mymain(void)
 DO_TEST_FORMAT("paravirt-cmdline-bogus-extra-root", false);
 DO_TEST("rbd-multihost-noauth");
 
+#ifdef LIBXL_HAVE_DEVICE_CHANNEL
+DO_TEST("channel-pty");
+DO_TEST("channel-unix");
+#endif
 #ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST
 DO_TEST("fullvirt-multiserial");
 #endif
-- 
2.1.4

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

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

[Joao Martins]

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.
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"}]}

There is just one thing unclear: is source "path" meant to be auto-generated
if it's not specified in the channel config? 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.

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.

Any comments or feedback is appreciated :)

Thanks,
Joao

Joao Martins (4):
  conf: add xen type for channels
  libxl: channels support
  xenconfig: channels conversion support
  xlconfigtest: add test for channel conversion

 docs/schemas/domaincommon.rng|  11 ++
 src/conf/domain_conf.c   |  18 +++-
 src/conf/domain_conf.h   |   1 +
 src/libxl/libxl_conf.c   |  81 ++
 src/libxl/libxl_domain.c |  38 +++
 src/qemu/qemu_command.c  |   1 +
 src/xenconfig/xen_xl.c   | 176 +++
 tests/xlconfigdata/test-channel-pty.cfg  |  13 +++
 tests/xlconfigdata/test-channel-pty.xml  |  33 ++
 tests/xlconfigdata/test-channel-unix.cfg |  13 +++
 tests/xlconfigdata/test-channel-unix.xml |  34 ++
 tests/xlconfigtest.c |   4 +
 12 files changed, 419 insertions(+), 4 deletions(-)
 create mode 100644 tests/xlconfigdata/test-channel-pty.cfg
 create mode 100644 tests/xlconfigdata/test-channel-pty.xml
 create mode 100644 tests/xlconfigdata/test-channel-unix.cfg
 create mode 100644 tests/xlconfigdata/test-channel-unix.xml

-- 
2.1.4

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

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

[Joao Martins]

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 <joao.m.mart...@oracle.com>
---
 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:
+virBufferAddLit(, "socket,");
+break;
+default:
+goto cleanup;
+}
+
+/* path */
+if (sourceType == VIR_DOMAIN_CHR_TYPE_UNIX)
+virBufferAsprintf(, "path=%s,", channel->source.data.nix.path);
+
+/* name */
+virBufferAsprintf(, "na