Re: [libvirt] [PATCH 0/4] libxl: implement some chuncks of the NUMA interface
On lun, 2013-07-01 at 15:27 -0600, Eric Blake wrote: On 07/01/2013 03:20 PM, Jim Fehlig wrote: What I'm really not sure about is patch 03, which is something I need if I want patch 04 to function properly. Basically it is about advertising that the libxl driver supports VIR_TYPED_PARAM_STRING. I looked at how that is done in the qemu driver, but I'm not entirely sure I completely understood the logic behind it, so, please, tell me if I missed or misinterpreted anything! I think we'll need another libvirt dev more familiar with this to verify, but afaict advertising that the driver supports VIR_TYPED_PARAM_STRING is required when returning a string in virTypedParam, for compatibility with older libvirt clients. Without it, strings wouldn't be returned to newer clients that support VIR_TYPED_PARAM_STRING. Any new API added after VIR_TYPED_PARAM_STRING was added can unconditionally assume that all callers are prepared to handle the string. But for APIs that were created before string support was added, even if your driver doesn't implement the API until now, you are correct that you must advertise support for strings before returning any strings. Ok, I think I've understood this better now... I'll do as Jim suggest, and add the proper bits to the functions, in the libxl driver, that need them. Thanks and Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] libxl: implement some chuncks of the NUMA interface
On lun, 2013-07-01 at 15:20 -0600, Jim Fehlig wrote: On 06/28/2013 08:32 AM, Dario Faggioli wrote: Hi Jim, Everyone, First patch series, so maybe a small introduction is required: I'm Dario and I work for Citrix on improving the NUMA support of Xen. Welcome Dario! Hey! :-) Basically, I'm enhancing capability reporting, to cover NUMA topology (patch 01), and I'm implementing nodeGetCellsFreeMemory (patch 02) and virDomainGetNumaParameters (patch 04) for the libxl driver. This last one requires at least Xen 4.3, so I put the implementation within the proper #ifdef-ery. Ok, I'll comment in the individual patches too. So, I just released v2, in which I think I addressed all the comments raised in this round... Let me know what you think. Thanks again and Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] libxl: implement some chuncks of the NUMA interface
On 06/28/2013 08:32 AM, Dario Faggioli wrote: Hi Jim, Everyone, First patch series, so maybe a small introduction is required: I'm Dario and I work for Citrix on improving the NUMA support of Xen. Welcome Dario! This patch series implements some of the missing bits and pieces, in the libxl driver, regarding obtaining per-host and per-domain NUMA related information. It's not the full libvirt NUMA interface, since we don't have all we would need for that in Xen yet (we will in the next version, 4.4), but it's certainly better than having nothing! :-) Yep, incremental improvements are fine. Basically, I'm enhancing capability reporting, to cover NUMA topology (patch 01), and I'm implementing nodeGetCellsFreeMemory (patch 02) and virDomainGetNumaParameters (patch 04) for the libxl driver. This last one requires at least Xen 4.3, so I put the implementation within the proper #ifdef-ery. Ok, I'll comment in the individual patches too. What I'm really not sure about is patch 03, which is something I need if I want patch 04 to function properly. Basically it is about advertising that the libxl driver supports VIR_TYPED_PARAM_STRING. I looked at how that is done in the qemu driver, but I'm not entirely sure I completely understood the logic behind it, so, please, tell me if I missed or misinterpreted anything! I think we'll need another libvirt dev more familiar with this to verify, but afaict advertising that the driver supports VIR_TYPED_PARAM_STRING is required when returning a string in virTypedParam, for compatibility with older libvirt clients. Without it, strings wouldn't be returned to newer clients that support VIR_TYPED_PARAM_STRING. In particular, should I have added more of those flags = ~VIR_TYPED_PARAM_STRING_OKAY; statements, as it happens in the qemu driver? If yes, in which functions? Once the driver advertises VIR_TYPED_PARAM_STRING, I think the functions taking virTypedParamPtr as a parameter must accommodate that, at least the getters. E.g. qemuDomainGetSchedulerParametersFlags() in the qemu driver has virCheckFlags(VIR_DOMAIN_AFFECT_LIVE | VIR_DOMAIN_AFFECT_CONFIG | VIR_TYPED_PARAM_STRING_OKAY, -1); /* We don't return strings, and thus trivially support this flag. */ flags = ~VIR_TYPED_PARAM_STRING_OKAY; I think the same applies for libxlDomainGetSchedulerParametersFlags(), which looks to be the only getter function in the libxl driver taking virTypedParam. Finally, allow me to say that it was a while that I wanted start hacking a bit on libvirt. I'm really glad I've eventually been able to do so, and I definitely plan to continue (with particular focus on NUMA related stuff). Great to hear and looking forward to your work! Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] libxl: implement some chuncks of the NUMA interface
On 07/01/2013 03:20 PM, Jim Fehlig wrote: What I'm really not sure about is patch 03, which is something I need if I want patch 04 to function properly. Basically it is about advertising that the libxl driver supports VIR_TYPED_PARAM_STRING. I looked at how that is done in the qemu driver, but I'm not entirely sure I completely understood the logic behind it, so, please, tell me if I missed or misinterpreted anything! I think we'll need another libvirt dev more familiar with this to verify, but afaict advertising that the driver supports VIR_TYPED_PARAM_STRING is required when returning a string in virTypedParam, for compatibility with older libvirt clients. Without it, strings wouldn't be returned to newer clients that support VIR_TYPED_PARAM_STRING. Any new API added after VIR_TYPED_PARAM_STRING was added can unconditionally assume that all callers are prepared to handle the string. But for APIs that were created before string support was added, even if your driver doesn't implement the API until now, you are correct that you must advertise support for strings before returning any strings. About the only API I know of off-hand that uses typed parameters but was added after string support is the latest incantation of migration via parameters. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/4] libxl: implement some chuncks of the NUMA interface
Hi Jim, Everyone, First patch series, so maybe a small introduction is required: I'm Dario and I work for Citrix on improving the NUMA support of Xen. This patch series implements some of the missing bits and pieces, in the libxl driver, regarding obtaining per-host and per-domain NUMA related information. It's not the full libvirt NUMA interface, since we don't have all we would need for that in Xen yet (we will in the next version, 4.4), but it's certainly better than having nothing! :-) Basically, I'm enhancing capability reporting, to cover NUMA topology (patch 01), and I'm implementing nodeGetCellsFreeMemory (patch 02) and virDomainGetNumaParameters (patch 04) for the libxl driver. This last one requires at least Xen 4.3, so I put the implementation within the proper #ifdef-ery. What I'm really not sure about is patch 03, which is something I need if I want patch 04 to function properly. Basically it is about advertising that the libxl driver supports VIR_TYPED_PARAM_STRING. I looked at how that is done in the qemu driver, but I'm not entirely sure I completely understood the logic behind it, so, please, tell me if I missed or misinterpreted anything! In particular, should I have added more of those flags = ~VIR_TYPED_PARAM_STRING_OKAY; statements, as it happens in the qemu driver? If yes, in which functions? Finally, allow me to say that it was a while that I wanted start hacking a bit on libvirt. I'm really glad I've eventually been able to do so, and I definitely plan to continue (with particular focus on NUMA related stuff). Comments are of course more than welcome. :-) Thanks and Regards, Dario --- Dario Faggioli (4): libxl: implement NUMA capabilities reporting libxl: implement per NUMA node free memory reporting libxl: advertise the support for VIR_TYPED_PARAM_STRING libxl: implement virDomainGetNumaParameters src/libxl/libxl_conf.c | 128 +- src/libxl/libxl_driver.c | 199 ++ 2 files changed, 326 insertions(+), 1 deletion(-) -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
