[libvirt] [PATCH v2 2/2] qemu: Refresh capabilities when creating resctrl allocation

Peter Krempa pkrempa at redhat.com
Fri Feb 2 17:05:56 UTC 2018


On Fri, Feb 02, 2018 at 15:27:22 +0100, Martin Kletzander wrote:
> Since one of the things in capabilities (info from resctrl updated with data
> about caches) can be change on the system by remounting the /sys/fs/resctrl with
> different options, the capabilities need to be refreshed.  There is a better fix
> in the works, but it's going to be way bigger than this (hence the XXX note
> there), so for the time being let's workaround this.  And in order not to slow
> down the domain starting, only get the capabilities if there are any cachetunes.
> 
> Relates-to: https://bugzilla.redhat.com/show_bug.cgi?id=1540780
> 
> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
> ---
>  src/qemu/qemu_process.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 5a364730c8c1..2ab242b7634d 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -2514,9 +2514,15 @@ qemuProcessResctrlCreate(virQEMUDriverPtr driver,
>  {
>      int ret = -1;
>      size_t i = 0;
> -    virCapsPtr caps = virQEMUDriverGetCapabilities(driver, false);
> +    virCapsPtr caps = NULL;
>      qemuDomainObjPrivatePtr priv = vm->privateData;
>  
> +    if (!vm->def->ncachetunes)
> +        return 0;
> +
> +    /* Force capability refresh since resctrl info can change
> +     * XXX: move cache info into virresctrl so caps are not needed */
> +    caps = virQEMUDriverGetCapabilities(driver, true);

I hope that your upcoming fix will also deal with the hugepage and NUMa
data which is more often used than this.

My feelings towards doing this are slightly mixed, but ACK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180202/38876f76/attachment-0001.sig>


More information about the libvir-list mailing list