From nobody Mon Sep 14 04:51:57 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) client-ip=38.145.34.151; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1788778210; cv=none; d=zohomail.com; s=zohoarc; b=bNh1DiqduKcAYvo2qKVT45I+QhgbtEqFz9QolePkgea+IfqkXI0eyN6QNMMrpddIBAg5k4POXDMZzNueIehM93mxsnkffLLmToZn0kT5eNqOB0sEXLWUBvT2NLVzbpKMv8NL0WSBP+KqpbUIz4eUaeEccMMi8G8ryxqZsqm0SxA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788778210; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=MrpSukn0EAV7YKdoxb3PpxWNyeTKbWdrGYUu5M3+/60=; b=gHkAGScqoOBcV86LKEFKEXl4RVY2ESmu6XaI8oIphFQKJ9yxpWrKWp6IR6X3drXgVUbFJrg0c+6bBv+/WaJ/XBXCwxZrxq+kJK87+qRpQZ2yc/rtMEtyW8cNPWmtqz265mHYiVPB5AJupFMETHuVXvIrQLl6Lmt634mCMgjawOc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [38.145.34.151]) by mx.zohomail.com with SMTPS id 1788778210234862.2135089114788; Mon, 7 Sep 2026 03:50:10 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 993) id E3FAF417E8; Mon, 7 Sep 2026 06:50:07 -0400 (EDT) Received: from [172.19.199.13] (unknown [10.16.107.18]) by lists.libvirt.org (Postfix) with ESMTP id 9B9263F89E for ; Mon, 7 Sep 2026 06:46:43 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 993) id C34AD3F323; Mon, 7 Sep 2026 06:46:23 -0400 (EDT) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id B35033F2F7 for ; Mon, 7 Sep 2026 06:46:21 -0400 (EDT) Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2026 03:46:19 -0700 Received: from ubuntu.ger.corp.intel.com ([10.211.96.193]) by fmviesa007.fm.intel.com with ESMTP; 07 Sep 2026 03:46:17 -0700 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788777982; x=1820313982; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0z82OzqNC1DKb3hk/EaHLpuLyoCUR1mgTgcC8N+ofnA=; b=AyFXkBqQma99xERHktOQYIje0Jkq/kzobQqGDSSP5TW5B6qWKfZyZQez XHm7pYbHODE/h5pz0uxlj0Bt2+Uke+aVAtd9/n97kUQW35L7lJrVmGx7d nwdggQKwbCQYtzLBN4eOSfUNJOmN/s/bZpMuutomvPYkdXJi3hqb4K7MN jTdaG9GfrfQQ+ylPh83Ue/8DrRBJRvteKiXV3ObreEuCsNbbKzDzcDkD2 YQRoikGS0eVK+M56r93iw5ZI7TWOeHKEjZXr+DoOneaWw4iMgiwyxaWPH SBvdkjdQYvAMqjaPlWD0FBFrf0R4HaXwOwZsaCNwMv0MFzgx2wc5XiyEa g==; X-CSE-ConnectionGUID: 36UAJVWZSDmsM/b21fr/ow== X-CSE-MsgGUID: GtYz1ZL8QLiBQVJDNgxwrg== X-IronPort-AV: E=McAfee;i="6800,10657,11898"; a="89109059" X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="89109059" X-CSE-ConnectionGUID: xg+wfzc/SYmQi87HxNzrUg== X-CSE-MsgGUID: hDOfCA+jQzK8pNKDROIdlQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="267431571" From: Jedrzej Wasiukiewicz To: devel@lists.libvirt.org Subject: [PATCH v2 1/4] conf: allow omitting vcpus in cachetune/memorytune/energytune Date: Mon, 7 Sep 2026 12:47:08 +0200 Message-ID: <20260907104711.2303928-2-jedrzej.wasiukiewicz@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> References: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ATFEWXSDKBT6IBYVJLZE6RKWL676AW7T X-Message-ID-Hash: ATFEWXSDKBT6IBYVJLZE6RKWL676AW7T X-MailFrom: jedrzej.wasiukiewicz@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Christopher M . Cantalupo" , Michal Privoznik X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1788778214938154100 Content-Type: text/plain; charset="utf-8" Make the vcpus attribute optional on cachetune, memorytune and energytune. Not specifying vcpus in the XML makes the allocation/monitoring group affect the whole domain process, relying on the resctrl inheritance mechanism so that all of the process' threads and children end up in the same group. Signed-off-by: Jedrzej Wasiukiewicz Reviewed-by: Christopher M. Cantalupo --- docs/formatdomain.rst | 57 ++++++++++++++++++------------- src/conf/schemas/domaincommon.rng | 48 ++++++++++++++++---------- 2 files changed, 63 insertions(+), 42 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 5a278f3717..e4eb2d9ba3 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -1029,10 +1029,13 @@ CPU Tuning Optional ``cachetune`` element can control allocations for CPU caches u= sing the resctrl on the host. Whether or not is this supported can be gather= ed from capabilities where some limitations like minimum size and required - granularity are reported as well. The required attribute ``vcpus`` spec= ifies - to which vCPUs this allocation applies. A vCPU can only be member of one - ``cachetune`` element allocation. The vCPUs specified by cachetune can = be - identical with those in memorytune, however they are not allowed to ove= rlap. + granularity are reported as well. The optional attribute ``vcpus`` spec= ifies + to which vCPUs this allocation applies. If ``vcpus`` is omitted the all= ocation + applies to the whole emulator process; the resctrl group is then inheri= ted by + all its threads and child processes. A vCPU can only be member of one + ``cachetune`` element allocation. The scope specified by cachetune + can be identical with those in memorytune, however they are not + allowed to overlap. The optional, output only ``id`` attribute identifies cache uniquely. Supported subelements are: =20 @@ -1059,23 +1062,26 @@ CPU Tuning specified, defaults to bytes. =20 ``monitor`` :since:`Since 4.10.0` - The optional element ``monitor`` creates the cache monitor(s) for cu= rrent - cache allocation and has the following required attributes: + The optional element ``monitor`` creates the cache monitor(s) for + the enclosing ``cachetune`` allocation. It has the following attribu= tes: =20 ``level`` - Host cache level the monitor belongs to. + Required. Host cache level the monitor belongs to. ``vcpus`` - vCPU list the monitor applies to. A monitor's vCPU list can only = be the - member(s) of the vCPU list of the associated allocation. The defa= ult - monitor has the same vCPU list as the associated allocation. For - non-default monitors, overlapping vCPUs are not permitted. + Optional. The vCPUs to monitor. Must be a subset of the enclosing + allocation's vCPUs and must not overlap another cache monitor of = the + same allocation. A monitor covering the allocation's full vCPU li= st + reports the allocation as a whole. Omit ``vcpus`` to inherit the + enclosing allocation's scope. =20 ``memorytune`` :since:`Since 4.7.0` Optional ``memorytune`` element can control allocations for memory band= width using the resctrl on the host. Whether or not is this supported can be gathered from capabilities where some limitations like minimum bandwidt= h and - required granularity are reported as well. The required attribute ``vcp= us`` - specifies to which vCPUs this allocation applies. A vCPU can only be me= mber + required granularity are reported as well. The optional attribute ``vcp= us`` + specifies to which vCPUs this allocation applies. If ``vcpus`` is omitt= ed the + allocation applies to the whole emulator process; the resctrl group is = then + inherited by all its threads and child processes. A vCPU can only be me= mber of one ``memorytune`` element allocation. The ``vcpus`` specified by ``memorytune`` can be identical to those specified by ``cachetune``. Ho= wever they are not allowed to overlap each other. Supported subelements are: @@ -1094,21 +1100,24 @@ CPU Tuning configuration. =20 ``energytune`` :since:`Since 12.4.0` - Optional ``energytune`` element allows to monitor energy consumption us= ing the - resctrl filesystem on the host. Whether or not is this supported can be - gathered from capabilities where number of monitors and available featu= res are - reported. The required attribute ``vcpus`` specifies to which allocatio= n group - this monitor belongs. A vCPU can only be member of one allocation group= and monitor - group. The ``vcpus`` specified by ``energytune`` can be identical to th= ose - specified by ``cachetune`` or ``memorytune``. However they are not allo= wed to - overlap each other. Supported subelements are: + Optional ``energytune`` element defines a group for energy consumption + monitoring using the resctrl filesystem on the host. Whether or not is = this + supported can be gathered from capabilities where number of monitors and + available features are reported. The optional attribute ``vcpus`` speci= fies + which vCPUs form this group. If ``vcpus`` is omitted the group covers t= he whole + emulator process; the resctrl group is then inherited by all its thread= s and + child processes. A vCPU can only be member of one ``energytune`` group.= The + ``vcpus`` specified by ``energytune`` can be identical to those specifi= ed by + ``cachetune`` or ``memorytune``. However they are not allowed to overla= p each + other. Supported subelements are: =20 ``monitor`` - The optional element ``monitor`` creates the energy monitor for - this allocation group and has the following required attribute: + The optional element creates the energy monitor for the + enclosing ``energytune`` group. It has the following attribute: =20 ``vcpus`` - vCPU list the monitor applies to. + Optional. The vCPUs to monitor. Omit ``vcpus`` to inherit the enc= losing + group's scope. =20 =20 Memory Allocation diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincom= mon.rng index 887fb8f808..0c0a3597a9 100644 --- a/src/conf/schemas/domaincommon.rng +++ b/src/conf/schemas/domaincommon.rng @@ -1229,9 +1229,11 @@ - - - + + + + + @@ -1266,9 +1268,11 @@ - - - + + + + + @@ -1276,9 +1280,11 @@ - - - + + + + + @@ -1290,9 +1296,11 @@ - - - + + + + + @@ -1300,9 +1308,11 @@ - - - + + + + + @@ -1310,9 +1320,11 @@ - - - + + + + + --=20 2.43.0 --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydz= ial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-31= 6 | Kapital zakladowy 200.000 PLN. Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu usta= wy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w trans= akcjach handlowych. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata= i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wi= adomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiek= olwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). If you are not the intended recipient= , please contact the sender and delete all copies; any review or distributi= on by others is strictly prohibited. From nobody Mon Sep 14 04:51:57 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) client-ip=38.145.34.151; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1788778672; cv=none; d=zohomail.com; s=zohoarc; b=lsZBJZhvYsfsX4FeC1SP+Idh8v6hdPBiY5hNCFk5HnGv7IgxEE6btetoqevct0+MOVaaViw/ZhKz9G5uCxTpV1PI6+QNGQtbKG6NZsZc7kWcxHTOBYgiYtY8MSbKbM9d0TnZbklph5HdfcDp9KamMYm07vcf6xsq5Fdx5qoQNxk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788778672; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=WO32LlwwLqGMH/Qz8z7u8mohC7LncZpXp5QIbULTjfQ=; b=WnWWynNpvqCsOrDj9a1qlmx2L57liYmZUKtkHm3R6n1C6L8pVFlE1+UFacP8rb47EJDUfThul2AUtu0DNIvAMWQq2pCVDUqkIIK1C/u9gLAwCFq25sTfG0DOR84gXXV3wI+NPoDGu4zWnZ98TTAw4RqMsiyvK10V23f9uVI0E8s= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [38.145.34.151]) by mx.zohomail.com with SMTPS id 1788778672051219.38765852254676; Mon, 7 Sep 2026 03:57:52 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 32CCF3F8C6; Mon, 7 Sep 2026 06:57:50 -0400 (EDT) Received: from [172.19.199.13] (unknown [10.16.107.18]) by lists.libvirt.org (Postfix) with ESMTP id 8BBCE41B5E for ; Mon, 7 Sep 2026 06:47:00 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 0EE343F2E6; Mon, 7 Sep 2026 06:46:27 -0400 (EDT) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 5FF4A3F31C for ; Mon, 7 Sep 2026 06:46:21 -0400 (EDT) Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2026 03:46:20 -0700 Received: from ubuntu.ger.corp.intel.com ([10.211.96.193]) by fmviesa007.fm.intel.com with ESMTP; 07 Sep 2026 03:46:19 -0700 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788777983; x=1820313983; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=QGPfHJdmFwj0xaHpgk2dURdZ2sgWOJJZLAqM2nlZYhw=; b=NxOQ/flLz3GYTaJVa30ViyeOHifAfnmxcjRVM3Cnq8M3ul4ZEaJsJgHj U/+vcyWeBIEFnrP9wW5TTeRQ+P9ctkbUpENKr4XPyuK1ga4WJMdl4icrk NMLwPKslRMNc7AnKI/B+MOqHtweq/wTqSWgL3Vzrpq4Z5XZjJy+CpZkkD i/+pPflTXkcO5kTogNBshPnp8qi5HOGsq3piQyeTW3yyLuyglkBfY41zX +ck2nlrtMTpYEUQ7Sa6kNT6ehlLmdb05ODVWroWzTlNhBwT1CwLo8f1Kl UfPO1QXwgCO28bh5W5q7j032sXf70fucm47b7p0RvjFewByqNbXg0kCaQ g==; X-CSE-ConnectionGUID: HO0ETkWhSBuX348w4AkPPQ== X-CSE-MsgGUID: 0VKj7c9WSV67OEr0NHrDAQ== X-IronPort-AV: E=McAfee;i="6800,10657,11898"; a="89109065" X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="89109065" X-CSE-ConnectionGUID: MGhhfCMYSdqbJ+Qv8eW5Zw== X-CSE-MsgGUID: /TCNBiJxR/aWx1zxu6hMdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="267431585" From: Jedrzej Wasiukiewicz To: devel@lists.libvirt.org Subject: [PATCH v2 2/4] conf: implement whole-process resctrl scope Date: Mon, 7 Sep 2026 12:47:09 +0200 Message-ID: <20260907104711.2303928-3-jedrzej.wasiukiewicz@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> References: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: MKJEON2FX7RY4PY3WBZWRO6PU2KCZXAA X-Message-ID-Hash: MKJEON2FX7RY4PY3WBZWRO6PU2KCZXAA X-MailFrom: jedrzej.wasiukiewicz@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Christopher M . Cantalupo" , Michal Privoznik X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1788778674917154100 Content-Type: text/plain; charset="utf-8" Treat vCPU attribute absence as a request to place the whole emulator process in one resctrl group for both allocation and monitoring. Parsing such XML failed until now. A whole-process group has no vCPU list. It formats back as a bare cachetune, memorytune, energytune or monitor element. Track the scope with a whole_process flag and enforce the rules beside the existing monitor checks. A domain's allocations are either all whole-process or all per-vCPU. A whole-process monitor needs a whole-process allocation, does not mix with explicit monitors and is unique per resource type. A whole-process allocation may still carry explicit per-vCPU monitors, as it already spans every thread. Monitors that omit vcpus inside an explicit allocation inherit the allocation's vcpu scope instead of covering the whole process. This behavior represents the resctrl dependency between allocation and monitoring. Out of range and empty vcpus attributes still remain silently dropped. Signed-off-by: Jedrzej Wasiukiewicz Reviewed-by: Christopher M. Cantalupo --- src/conf/domain_conf.c | 231 ++++++++++++------ src/conf/domain_conf.h | 2 + .../cachetune-monitor-empty-vcpus.xml | 30 +++ .../cachetune-monitor-inherit-alloc.xml | 30 +++ .../cachetune-wholeprocess-duplicate.xml | 32 +++ ...chetune-wholeprocess-monitor-duplicate.xml | 31 +++ .../cachetune-wholeprocess-monitors.xml | 31 +++ .../energytune-colliding-monitor.xml | 30 +++ .../energytune-wholeprocess.xml | 29 +++ .../memorytune-wholeprocess.xml | 29 +++ .../resctrl-wholeprocess-alloc-monitor.xml | 32 +++ .../resctrl-wholeprocess-layering.xml | 32 +++ .../resctrl-wholeprocess-monitors.xml | 33 +++ .../cachetune-monitor-inherit-alloc.xml | 30 +++ tests/genericxml2xmltest.c | 11 + 15 files changed, 545 insertions(+), 68 deletions(-) create mode 100644 tests/genericxml2xmlindata/cachetune-monitor-empty-vcpu= s.xml create mode 100644 tests/genericxml2xmlindata/cachetune-monitor-inherit-al= loc.xml create mode 100644 tests/genericxml2xmlindata/cachetune-wholeprocess-dupli= cate.xml create mode 100644 tests/genericxml2xmlindata/cachetune-wholeprocess-monit= or-duplicate.xml create mode 100644 tests/genericxml2xmlindata/cachetune-wholeprocess-monit= ors.xml create mode 100644 tests/genericxml2xmlindata/energytune-colliding-monitor= .xml create mode 100644 tests/genericxml2xmlindata/energytune-wholeprocess.xml create mode 100644 tests/genericxml2xmlindata/memorytune-wholeprocess.xml create mode 100644 tests/genericxml2xmlindata/resctrl-wholeprocess-alloc-m= onitor.xml create mode 100644 tests/genericxml2xmlindata/resctrl-wholeprocess-layerin= g.xml create mode 100644 tests/genericxml2xmlindata/resctrl-wholeprocess-monitor= s.xml create mode 100644 tests/genericxml2xmloutdata/cachetune-monitor-inherit-a= lloc.xml diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 34d3b00079..c1a4b8f26e 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -18814,15 +18814,17 @@ virDomainDefParseBootOptions(virDomainDef *def, static int virDomainResctrlParseVcpus(virDomainDef *def, xmlNodePtr node, - virBitmap **vcpus) + virBitmap **vcpus, + bool *whole_process) { g_autofree char *vcpus_str =3D NULL; + *vcpus =3D NULL; =20 vcpus_str =3D virXMLPropString(node, "vcpus"); - if (!vcpus_str) { - virReportError(VIR_ERR_XML_ERROR, _("Missing %1$s attribute 'vcpus= '"), - node->name); - return -1; + *whole_process =3D !vcpus_str; + if (*whole_process) { + *vcpus =3D virBitmapNew(0); + return 0; } if (virBitmapParse(vcpus_str, vcpus, VIR_DOMAIN_CPUMASK_LEN) < 0) { virReportError(VIR_ERR_XML_ERROR, @@ -18902,6 +18904,9 @@ virDomainCachetuneDefParseCache(xmlXPathContextPtr = ctxt, /* Checking if the monitor's vcpus and tag is conflicted with existing * allocation and monitors. * + * A whole-process monitor must not be mixed with explicit monitors and may + * cover each resource type only once. + * * Returns 1 if @monitor->vcpus equals to @resctrl->vcpus, then the monitor * will share the underlying resctrl group with @resctrl->alloc. Returns -1 * if any conflict found. Returns 0 if no conflict and @monitor->vcpus is @@ -18918,17 +18923,40 @@ virDomainResctrlValidateMonitor(virDomainResctrlD= ef *resctrl, bool vcpus_overlap_no_resctrl =3D false; bool default_alloc_monitor =3D virResctrlAllocIsEmpty(resctrl->alloc); =20 + if (resctrl->nmonitors > 0 && + resctrl->monitors[0]->whole_process !=3D monitor->whole_process) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("Whole-process and explicit monitors cannot be mi= xed")); + return -1; + } + + if (monitor->whole_process) { + for (i =3D 0; i < resctrl->nmonitors; i++) { + if (resctrl->monitors[i]->tag =3D=3D monitor->tag) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("Duplicate whole-process monitor of the s= ame resource type")); + return -1; + } + } + + return 0; + } + if (virBitmapIsAllClear(monitor->vcpus)) { virReportError(VIR_ERR_INVALID_ARG, "%s", _("vcpus is empty")); return -1; } =20 - while ((vcpu =3D virBitmapNextSetBit(monitor->vcpus, vcpu)) >=3D 0) { - if (!virBitmapIsBitSet(resctrl->vcpus, vcpu)) { - virReportError(VIR_ERR_INVALID_ARG, "%s", - _("Monitor vcpus conflicts with allocation")); - return -1; + /* A whole-process allocation covers every thread, so it does not cons= train + * an explicit monitor's vcpus. */ + if (!resctrl->whole_process) { + while ((vcpu =3D virBitmapNextSetBit(monitor->vcpus, vcpu)) >=3D 0= ) { + if (!virBitmapIsBitSet(resctrl->vcpus, vcpu)) { + virReportError(VIR_ERR_INVALID_ARG, "%s", + _("Monitor vcpus conflicts with allocation"= )); + return -1; + } } } =20 @@ -18995,6 +19023,7 @@ virDomainResctrlMonDefParse(virDomainDef *def, =20 for (i =3D 0; i < n; i++) { g_autofree char *id =3D NULL; + bool whole_process =3D false; =20 domresmon =3D g_new0(virDomainResctrlMonDef, 1); =20 @@ -19020,27 +19049,41 @@ virDomainResctrlMonDefParse(virDomainDef *def, } } =20 - if (virDomainResctrlParseVcpus(def, nodes[i], &domresmon->vcpus) <= 0) + if (virDomainResctrlParseVcpus(def, nodes[i], &domresmon->vcpus, + &whole_process) < 0) goto cleanup; =20 + /* A monitor that omits vcpus inside an explicit allocation inheri= ts + * the allocation's vcpu scope instead of covering the whole proce= ss. */ + if (whole_process && !resctrl->whole_process) { + virBitmapFree(domresmon->vcpus); + domresmon->vcpus =3D virBitmapNewCopy(resctrl->vcpus); + whole_process =3D false; + } + + domresmon->whole_process =3D whole_process; + rv =3D virDomainResctrlValidateMonitor(resctrl, domresmon); if (rv < 0) goto cleanup; =20 - /* If monitor's vcpu list is identical to the vcpu list of the - * associated allocation, set monitor's id to the same value - * as the allocation. */ - if (rv =3D=3D 1) { - id =3D g_strdup(virResctrlAllocGetID(resctrl->alloc)); - } else { - g_autofree char *tmp =3D virBitmapFormat(domresmon->vcpus); + /* A whole-process monitor keeps its id unset, which selects the b= are + * machine name. Otherwise, if the monitor's vcpu list is identica= l to + * the vcpu list of the associated allocation, share the allocatio= n's + * id. */ + if (!whole_process) { + if (rv =3D=3D 1) { + id =3D g_strdup(virResctrlAllocGetID(resctrl->alloc)); + } else { + g_autofree char *tmp =3D virBitmapFormat(domresmon->vcpus); =20 - id =3D g_strdup_printf("vcpus_%s", tmp); + id =3D g_strdup_printf("vcpus_%s", tmp); + } } =20 virResctrlMonitorSetAlloc(domresmon->instance, resctrl->alloc); =20 - if (virResctrlMonitorSetID(domresmon->instance, id) < 0) + if (id && virResctrlMonitorSetID(domresmon->instance, id) < 0) goto cleanup; =20 VIR_APPEND_ELEMENT(resctrl->monitors, resctrl->nmonitors, domresmo= n); @@ -19057,39 +19100,64 @@ static virDomainResctrlDef * virDomainResctrlNew(xmlNodePtr node, virResctrlAlloc *alloc, virBitmap *vcpus, + bool whole_process, unsigned int flags) { virDomainResctrlDef *resctrl =3D NULL; g_autofree char *vcpus_str =3D NULL; g_autofree char *alloc_id =3D NULL; =20 - /* We need to format it back because we need to be consistent in the n= aming - * even when users specify some "sub-optimal" string there. */ - vcpus_str =3D virBitmapFormat(vcpus); + /* A whole-process group omits the "vcpus" suffix. */ + if (!whole_process) { + /* We need to format it back because we need to be consistent in t= he naming + * even when users specify some "sub-optimal" string there. */ + vcpus_str =3D virBitmapFormat(vcpus); =20 - if (!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE)) - alloc_id =3D virXMLPropString(node, "id"); + if (!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE)) + alloc_id =3D virXMLPropString(node, "id"); =20 - if (!alloc_id) { - /* The number of allocations is limited and the directory structur= e is flat, - * not hierarchical, so we need to have all same allocations in one - * directory, so it's nice to have it named appropriately. For no= w it's - * 'vcpus_...' but it's designed in order for it to be changeable = in the - * future (it's part of the status XML). */ - alloc_id =3D g_strdup_printf("vcpus_%s", vcpus_str); - } + if (!alloc_id) { + /* The number of allocations is limited and the directory stru= cture is flat, + * not hierarchical, so we need to have all same allocations i= n one + * directory, so it's nice to have it named appropriately. Fo= r now it's + * 'vcpus_...' but it's designed in order for it to be changea= ble in the + * future (it's part of the status XML). */ + alloc_id =3D g_strdup_printf("vcpus_%s", vcpus_str); + } =20 - if (virResctrlAllocSetID(alloc, alloc_id) < 0) - return NULL; + if (virResctrlAllocSetID(alloc, alloc_id) < 0) + return NULL; + } =20 resctrl =3D g_new0(virDomainResctrlDef, 1); resctrl->vcpus =3D virBitmapNewCopy(vcpus); + resctrl->whole_process =3D whole_process; resctrl->alloc =3D virObjectRef(alloc); =20 return resctrl; } =20 =20 +/* Whole-process and per-vcpu allocations cannot be mixed: assigning expli= cit + * vCPUs to their own group would pull them out of the whole-process group= . */ +static int +virDomainResctrlValidateScope(virDomainDef *def, + bool whole_process) +{ + size_t i; + + for (i =3D 0; i < def->nresctrls; i++) { + if (def->resctrls[i]->whole_process !=3D whole_process) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("Whole-process and per-vcpu resctrl allocatio= ns cannot be mixed")); + return -1; + } + } + + return 0; +} + + static int virDomainCachetuneDefParse(virDomainDef *def, xmlXPathContextPtr ctxt, @@ -19101,16 +19169,17 @@ virDomainCachetuneDefParse(virDomainDef *def, ssize_t i =3D 0; int n; int ret =3D -1; + bool whole_process =3D false; g_autoptr(virBitmap) vcpus =3D NULL; g_autofree xmlNodePtr *nodes =3D NULL; g_autoptr(virResctrlAlloc) alloc =3D NULL; =20 ctxt->node =3D node; =20 - if (virDomainResctrlParseVcpus(def, node, &vcpus) < 0) + if (virDomainResctrlParseVcpus(def, node, &vcpus, &whole_process) < 0) return -1; =20 - if (virBitmapIsAllClear(vcpus)) + if (!whole_process && virBitmapIsAllClear(vcpus)) return 0; =20 if ((n =3D virXPathNodeSet("./cache", ctxt, &nodes)) < 0) @@ -19125,6 +19194,9 @@ virDomainCachetuneDefParse(virDomainDef *def, return -1; } =20 + if (virDomainResctrlValidateScope(def, whole_process) < 0) + return -1; + if (!(alloc =3D virResctrlAllocNew())) return -1; =20 @@ -19133,7 +19205,7 @@ virDomainCachetuneDefParse(virDomainDef *def, return -1; } =20 - if (!(resctrl =3D virDomainResctrlNew(node, alloc, vcpus, flags))) + if (!(resctrl =3D virDomainResctrlNew(node, alloc, vcpus, whole_proces= s, flags))) return -1; =20 if (virDomainResctrlMonDefParse(def, ctxt, node, @@ -19469,15 +19541,16 @@ virDomainMemorytuneDefParse(virDomainDef *def, ssize_t i =3D 0; size_t nmons =3D 0; size_t ret =3D -1; + bool whole_process =3D false; =20 int n; =20 ctxt->node =3D node; =20 - if (virDomainResctrlParseVcpus(def, node, &vcpus) < 0) + if (virDomainResctrlParseVcpus(def, node, &vcpus, &whole_process) < 0) return -1; =20 - if (virBitmapIsAllClear(vcpus)) + if (!whole_process && virBitmapIsAllClear(vcpus)) return 0; =20 if ((n =3D virXPathNodeSet("./node", ctxt, &nodes)) < 0) @@ -19489,6 +19562,8 @@ virDomainMemorytuneDefParse(virDomainDef *def, if (resctrl) { alloc =3D virObjectRef(resctrl->alloc); } else { + if (virDomainResctrlValidateScope(def, whole_process) < 0) + return -1; if (!(alloc =3D virResctrlAllocNew())) return -1; } @@ -19504,7 +19579,8 @@ virDomainMemorytuneDefParse(virDomainDef *def, * just update the existing alloc information, which is done in above * virDomainMemorytuneDefParseMemory */ if (!resctrl) { - if (!(newresctrl =3D virDomainResctrlNew(node, alloc, vcpus, flags= ))) + if (!(newresctrl =3D virDomainResctrlNew(node, alloc, vcpus, + whole_process, flags))) return -1; =20 resctrl =3D newresctrl; @@ -19544,15 +19620,16 @@ virDomainEnergytuneDefParse(virDomainDef *def, virDomainResctrlDef *newresctrl =3D NULL; g_autoptr(virBitmap) vcpus =3D NULL; g_autoptr(virResctrlAlloc) alloc =3D NULL; + bool whole_process =3D false; size_t nmons; int ret =3D -1; =20 ctxt->node =3D node; =20 - if (virDomainResctrlParseVcpus(def, node, &vcpus) < 0) + if (virDomainResctrlParseVcpus(def, node, &vcpus, &whole_process) < 0) return -1; =20 - if (virBitmapIsAllClear(vcpus)) + if (!whole_process && virBitmapIsAllClear(vcpus)) return 0; =20 if (virDomainResctrlVcpuMatch(def, vcpus, &resctrl) < 0) @@ -19561,9 +19638,12 @@ virDomainEnergytuneDefParse(virDomainDef *def, if (resctrl) { alloc =3D virObjectRef(resctrl->alloc); } else { + if (virDomainResctrlValidateScope(def, whole_process) < 0) + return -1; if (!(alloc =3D virResctrlAllocNew())) return -1; - if (!(newresctrl =3D virDomainResctrlNew(node, alloc, vcpus, flags= ))) + if (!(newresctrl =3D virDomainResctrlNew(node, alloc, vcpus, + whole_process, flags))) return -1; resctrl =3D newresctrl; } @@ -28780,16 +28860,22 @@ virDomainResctrlMonDefFormatHelper(virDomainResct= rlMonDef *domresmon, if (domresmon->tag !=3D tag) return 0; =20 - virBufferAddLit(buf, "whole_process) { + virBufferAddLit(buf, "/>\n"); + return 0; + } + vcpus =3D virBitmapFormat(domresmon->vcpus); =20 - virBufferAsprintf(buf, "vcpus=3D'%s'/>\n", vcpus); + virBufferAsprintf(buf, " vcpus=3D'%s'/>\n", vcpus); =20 return 0; } @@ -28820,16 +28906,19 @@ virDomainCachetuneDefFormat(virBuffer *buf, if (!virBufferUse(&childrenBuf)) return 0; =20 - vcpus =3D virBitmapFormat(resctrl->vcpus); + /* A whole-process group has no vcpus and no id to format. */ + if (!resctrl->whole_process) { + vcpus =3D virBitmapFormat(resctrl->vcpus); =20 - virBufferAsprintf(&attrBuf, " vcpus=3D'%s'", vcpus); + virBufferAsprintf(&attrBuf, " vcpus=3D'%s'", vcpus); =20 - if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) { - const char *alloc_id =3D virResctrlAllocGetID(resctrl->alloc); - if (!alloc_id) - return -1; + if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) { + const char *alloc_id =3D virResctrlAllocGetID(resctrl->alloc); + if (!alloc_id) + return -1; =20 - virBufferAsprintf(&attrBuf, " id=3D'%s'", alloc_id); + virBufferAsprintf(&attrBuf, " id=3D'%s'", alloc_id); + } } =20 virXMLFormatElement(buf, "cachetune", &attrBuf, &childrenBuf); @@ -28877,16 +28966,19 @@ virDomainMemorytuneDefFormat(virBuffer *buf, if (!virBufferUse(&childrenBuf)) return 0; =20 - vcpus =3D virBitmapFormat(resctrl->vcpus); + /* A whole-process group has no vcpus and no id to format. */ + if (!resctrl->whole_process) { + vcpus =3D virBitmapFormat(resctrl->vcpus); =20 - virBufferAsprintf(&attrBuf, " vcpus=3D'%s'", vcpus); + virBufferAsprintf(&attrBuf, " vcpus=3D'%s'", vcpus); =20 - if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) { - const char *alloc_id =3D virResctrlAllocGetID(resctrl->alloc); - if (!alloc_id) - return -1; + if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) { + const char *alloc_id =3D virResctrlAllocGetID(resctrl->alloc); + if (!alloc_id) + return -1; =20 - virBufferAsprintf(&attrBuf, " id=3D'%s'", alloc_id); + virBufferAsprintf(&attrBuf, " id=3D'%s'", alloc_id); + } } =20 virXMLFormatElement(buf, "memorytune", &attrBuf, &childrenBuf); @@ -28915,15 +29007,18 @@ virDomainEnergytuneDefFormat(virBuffer *buf, if (!virBufferUse(&childrenBuf)) return 0; =20 - vcpus =3D virBitmapFormat(resctrl->vcpus); - virBufferAsprintf(&attrBuf, " vcpus=3D'%s'", vcpus); + /* A whole-process group has no vcpus and no id to format. */ + if (!resctrl->whole_process) { + vcpus =3D virBitmapFormat(resctrl->vcpus); + virBufferAsprintf(&attrBuf, " vcpus=3D'%s'", vcpus); =20 - if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) { - const char *alloc_id =3D virResctrlAllocGetID(resctrl->alloc); - if (!alloc_id) - return -1; + if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) { + const char *alloc_id =3D virResctrlAllocGetID(resctrl->alloc); + if (!alloc_id) + return -1; =20 - virBufferAsprintf(&attrBuf, " id=3D'%s'", alloc_id); + virBufferAsprintf(&attrBuf, " id=3D'%s'", alloc_id); + } } =20 virXMLFormatElement(buf, "energytune", &attrBuf, &childrenBuf); diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 3732525af4..5e4e9937a6 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -2937,12 +2937,14 @@ struct _virDomainCputune { =20 struct _virDomainResctrlMonDef { virBitmap *vcpus; + bool whole_process; virResctrlMonitorType tag; virResctrlMonitor *instance; }; =20 struct _virDomainResctrlDef { virBitmap *vcpus; + bool whole_process; virResctrlAlloc *alloc; =20 virDomainResctrlMonDef **monitors; diff --git a/tests/genericxml2xmlindata/cachetune-monitor-empty-vcpus.xml b= /tests/genericxml2xmlindata/cachetune-monitor-empty-vcpus.xml new file mode 100644 index 0000000000..a79ad71635 --- /dev/null +++ b/tests/genericxml2xmlindata/cachetune-monitor-empty-vcpus.xml @@ -0,0 +1,30 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/cachetune-monitor-inherit-alloc.xml= b/tests/genericxml2xmlindata/cachetune-monitor-inherit-alloc.xml new file mode 100644 index 0000000000..b8b0460d1f --- /dev/null +++ b/tests/genericxml2xmlindata/cachetune-monitor-inherit-alloc.xml @@ -0,0 +1,30 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/cachetune-wholeprocess-duplicate.xm= l b/tests/genericxml2xmlindata/cachetune-wholeprocess-duplicate.xml new file mode 100644 index 0000000000..c828b659f7 --- /dev/null +++ b/tests/genericxml2xmlindata/cachetune-wholeprocess-duplicate.xml @@ -0,0 +1,32 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/cachetune-wholeprocess-monitor-dupl= icate.xml b/tests/genericxml2xmlindata/cachetune-wholeprocess-monitor-dupli= cate.xml new file mode 100644 index 0000000000..898a51de87 --- /dev/null +++ b/tests/genericxml2xmlindata/cachetune-wholeprocess-monitor-duplicate.x= ml @@ -0,0 +1,31 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/cachetune-wholeprocess-monitors.xml= b/tests/genericxml2xmlindata/cachetune-wholeprocess-monitors.xml new file mode 100644 index 0000000000..550ae2df31 --- /dev/null +++ b/tests/genericxml2xmlindata/cachetune-wholeprocess-monitors.xml @@ -0,0 +1,31 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/energytune-colliding-monitor.xml b/= tests/genericxml2xmlindata/energytune-colliding-monitor.xml new file mode 100644 index 0000000000..f07da2620f --- /dev/null +++ b/tests/genericxml2xmlindata/energytune-colliding-monitor.xml @@ -0,0 +1,30 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/energytune-wholeprocess.xml b/tests= /genericxml2xmlindata/energytune-wholeprocess.xml new file mode 100644 index 0000000000..ebac5e9bc9 --- /dev/null +++ b/tests/genericxml2xmlindata/energytune-wholeprocess.xml @@ -0,0 +1,29 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/memorytune-wholeprocess.xml b/tests= /genericxml2xmlindata/memorytune-wholeprocess.xml new file mode 100644 index 0000000000..496fccc7e6 --- /dev/null +++ b/tests/genericxml2xmlindata/memorytune-wholeprocess.xml @@ -0,0 +1,29 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/resctrl-wholeprocess-alloc-monitor.= xml b/tests/genericxml2xmlindata/resctrl-wholeprocess-alloc-monitor.xml new file mode 100644 index 0000000000..ad0a904dc7 --- /dev/null +++ b/tests/genericxml2xmlindata/resctrl-wholeprocess-alloc-monitor.xml @@ -0,0 +1,32 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/resctrl-wholeprocess-layering.xml b= /tests/genericxml2xmlindata/resctrl-wholeprocess-layering.xml new file mode 100644 index 0000000000..aebd613d78 --- /dev/null +++ b/tests/genericxml2xmlindata/resctrl-wholeprocess-layering.xml @@ -0,0 +1,32 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmlindata/resctrl-wholeprocess-monitors.xml b= /tests/genericxml2xmlindata/resctrl-wholeprocess-monitors.xml new file mode 100644 index 0000000000..35f20c6c11 --- /dev/null +++ b/tests/genericxml2xmlindata/resctrl-wholeprocess-monitors.xml @@ -0,0 +1,33 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmloutdata/cachetune-monitor-inherit-alloc.xm= l b/tests/genericxml2xmloutdata/cachetune-monitor-inherit-alloc.xml new file mode 100644 index 0000000000..70dcf39285 --- /dev/null +++ b/tests/genericxml2xmloutdata/cachetune-monitor-inherit-alloc.xml @@ -0,0 +1,30 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 4 + + + + + + + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i386 + + + + + + + + diff --git a/tests/genericxml2xmltest.c b/tests/genericxml2xmltest.c index 169c71efa3..8492a6266e 100644 --- a/tests/genericxml2xmltest.c +++ b/tests/genericxml2xmltest.c @@ -211,6 +211,17 @@ mymain(void) DO_TEST("cachetune-cdp"); DO_TEST("cachetune"); DO_TEST("energytune"); + DO_TEST("energytune-wholeprocess"); + DO_TEST("memorytune-wholeprocess"); + DO_TEST("cachetune-wholeprocess-monitors"); + DO_TEST("resctrl-wholeprocess-monitors"); + DO_TEST("resctrl-wholeprocess-alloc-monitor"); + DO_TEST_FAIL_INACTIVE("resctrl-wholeprocess-layering"); + DO_TEST_FAIL_INACTIVE("cachetune-wholeprocess-duplicate"); + DO_TEST_FAIL_INACTIVE("cachetune-wholeprocess-monitor-duplicate"); + DO_TEST_DIFFERENT("cachetune-monitor-inherit-alloc"); + DO_TEST_FAIL_INACTIVE("energytune-colliding-monitor"); + DO_TEST_FAIL_INACTIVE("cachetune-monitor-empty-vcpus"); DO_TEST_DIFFERENT("cachetune-extra-tunes"); DO_TEST_FAIL_INACTIVE("cachetune-colliding-allocs"); DO_TEST_FAIL_INACTIVE("cachetune-colliding-tunes"); --=20 2.43.0 --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydz= ial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-31= 6 | Kapital zakladowy 200.000 PLN. Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu usta= wy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w trans= akcjach handlowych. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata= i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wi= adomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiek= olwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). If you are not the intended recipient= , please contact the sender and delete all copies; any review or distributi= on by others is strictly prohibited. From nobody Mon Sep 14 04:51:57 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) client-ip=38.145.34.151; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1788778390; cv=none; d=zohomail.com; s=zohoarc; b=hc+i2/6GtfRZcfVtHiDJMaqXsZCy6gUHPZn2f8eNgr8hEWJeoQsQpPwgqPbJ+uDq/0Sz1+1Y72vil9RNPLv3pNoPr6O3DC3EKEza09agfEKrG+cpO76F0n+lYBw4VUxk1AzArRYi+d112l0JrBonZq3/DKCLFGCUpOh+qMnH/Q0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788778390; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=hSjhmiqMXlrgtbd7anLcS+sLQk8YZWEGbbMAwdbU9PI=; b=UsfpZumXGw26M5nBHNSeCzjmOIV/Whs2LJfkflcNma3CC8KBTN6hr7sVwjkQf0/0uZKwuzyTo7kIo4bCd6Z1WVYj510ya1PdP3vqrpMCThbPb6Q2qi4ZrB8pMbyfysxdcb47OSP6uQHRyY04nXdVfUeNi7cz9cDGHDIPpRmQ+UA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [38.145.34.151]) by mx.zohomail.com with SMTPS id 1788778390013759.2053621045935; Mon, 7 Sep 2026 03:53:10 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 993) id EBAFA4185C; Mon, 7 Sep 2026 06:53:06 -0400 (EDT) Received: from [172.19.199.13] (unknown [10.16.107.18]) by lists.libvirt.org (Postfix) with ESMTP id 256A941ADD for ; Mon, 7 Sep 2026 06:46:54 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 78ED53F2F4; Mon, 7 Sep 2026 06:46:25 -0400 (EDT) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id A26303F31F for ; Mon, 7 Sep 2026 06:46:22 -0400 (EDT) Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2026 03:46:21 -0700 Received: from ubuntu.ger.corp.intel.com ([10.211.96.193]) by fmviesa007.fm.intel.com with ESMTP; 07 Sep 2026 03:46:20 -0700 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788777983; x=1820313983; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=iwX8juG0UakmsgFfx40xzZZ920h6Ft7aU8Tzpti8lQs=; b=TagEhCtvfqHP2BKWADr9LxIHCjWlYi4ftEDgYhGy0t1VqUQEOSVtPJqR Yp7+tkziHy3MFYBjuFUDSIADxTwCDKMkDLvZkEW1LFwNaIJ2ZkULt72xz Uvzhn20XEqroB68zrq3DfuJpNfBBkypqGu+XNtQHUkk2URAKHxxydx0zz kCqCMU0ZOvv7jqXnmteyNIO81UEyNvgB55mYo+uqJhqlEQYgeADJiajfm SZXi+Dspeqrwkq3xXDflbfs2VZgQ9g8y5vP+X0V+z3tTqrSN8UoEuDvJS kEQ04f6xewaNCmxz4NH6nfSxBsxOiaL0uTVd5wD44pty4YKYJKatSy0rr w==; X-CSE-ConnectionGUID: 2kqaMAsKSnOtGSX4eTkbqw== X-CSE-MsgGUID: B08dPTcwSYGuRWR3tE6UqA== X-IronPort-AV: E=McAfee;i="6800,10657,11898"; a="89109070" X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="89109070" X-CSE-ConnectionGUID: p14LnoK2T6iFcLijvbUerg== X-CSE-MsgGUID: YAOuxyAsTS2rRXcMMuab6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="267431603" From: Jedrzej Wasiukiewicz To: devel@lists.libvirt.org Subject: [PATCH v2 3/4] qemu: assign whole-process resctrl groups at domain start Date: Mon, 7 Sep 2026 12:47:10 +0200 Message-ID: <20260907104711.2303928-4-jedrzej.wasiukiewicz@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> References: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: KD24Q3IUQI2ETMFZ3G5AE5CCKU5DPF5U X-Message-ID-Hash: KD24Q3IUQI2ETMFZ3G5AE5CCKU5DPF5U X-MailFrom: jedrzej.wasiukiewicz@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Christopher M . Cantalupo" , Michal Privoznik X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1788778393381154100 Content-Type: text/plain; charset="utf-8" A whole-process resctrl group (allocation or monitor declared without vcpus) covers the entire emulator process rather than a set of vCPU threads. Assign the emulator PID to such groups during the pre-exec handshake in qemuProcessResctrlCreate, so every thread the QEMU process later spawns - vCPUs, iothreads, workers... - inherits the group. virResctrlDeterminePath now treats a NULL id as a whole-process group, resolving to the bare machine name with no id suffix. Signed-off-by: Jedrzej Wasiukiewicz Reviewed-by: Christopher M. Cantalupo --- src/qemu/qemu_process.c | 40 +++++++++++++++++++++++++++++++++++++--- src/util/virresctrl.c | 10 ++++------ 2 files changed, 41 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index aaa9046146..df447ecb04 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2925,18 +2925,33 @@ qemuProcessResctrlCreate(virQEMUDriver *driver, =20 for (i =3D 0; i < vm->def->nresctrls; i++) { size_t j =3D 0; + virDomainResctrlDef *resctrl =3D vm->def->resctrls[i]; + if (virResctrlAllocCreate(caps->host.resctrl, - vm->def->resctrls[i]->alloc, + resctrl->alloc, priv->machineName) < 0) return -1; =20 - for (j =3D 0; j < vm->def->resctrls[i]->nmonitors; j++) { + /* A whole-process group covers every emulator thread. + * Assign the emulator PID now, while still in the pre-exec handsh= ake + * window, so the resctrl group is inherited by every thread the Q= EMU + * process subsequently spawns (vCPUs, iothreads, workers etc.). */ + if (resctrl->whole_process && + !virResctrlAllocIsEmpty(resctrl->alloc) && + virResctrlAllocAddPID(resctrl->alloc, vm->pid) < 0) + return -1; + + for (j =3D 0; j < resctrl->nmonitors; j++) { virDomainResctrlMonDef *mon =3D NULL; =20 - mon =3D vm->def->resctrls[i]->monitors[j]; + mon =3D resctrl->monitors[j]; if (virResctrlMonitorCreate(mon->instance, priv->machineName) < 0) return -1; + + if (mon->whole_process && + virResctrlMonitorAddPID(mon->instance, vm->pid) < 0) + return -1; } } =20 @@ -6281,6 +6296,25 @@ qemuProcessSetupVcpu(virDomainObj *vm, size_t j =3D 0; virDomainResctrlDef *ct =3D vm->def->resctrls[i]; =20 + /* A whole-process allocation covers every thread: its control gro= up is + * assigned the emulator PID once at startup and inherited by every + * thread, so per-vCPU threads need no allocation assignment here. + * Per-vCPU monitors underneath it, however, still need each vCPU'= s PID + * to carve out their own mon_group. */ + if (ct->whole_process) { + for (j =3D 0; j < ct->nmonitors; j++) { + mon =3D ct->monitors[j]; + + if (virBitmapIsBitSet(mon->vcpus, vcpuid)) { + if (virResctrlMonitorAddPID(mon->instance, vcpupid) < = 0) + return -1; + break; + } + } + + continue; + } + if (virBitmapIsBitSet(ct->vcpus, vcpuid)) { if (virResctrlAllocAddPID(ct->alloc, vcpupid) < 0) return -1; diff --git a/src/util/virresctrl.c b/src/util/virresctrl.c index b3e5c34443..80de5997fa 100644 --- a/src/util/virresctrl.c +++ b/src/util/virresctrl.c @@ -2287,12 +2287,10 @@ virResctrlDeterminePath(const char *parentpath, const char *prefix, const char *id) { - if (!id) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Resctrl ID must be set before determining resctr= l parentpath=3D'%1$s' prefix=3D'%2$s'"), - parentpath, prefix); - return NULL; - } + /* A NULL id denotes a whole-process group, which uses the bare machine + * name with no id suffix. */ + if (!id) + return g_strdup_printf("%s/%s", parentpath, prefix); =20 return g_strdup_printf("%s/%s-%s", parentpath, prefix, id); } --=20 2.43.0 --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydz= ial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-31= 6 | Kapital zakladowy 200.000 PLN. Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu usta= wy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w trans= akcjach handlowych. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata= i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wi= adomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiek= olwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). If you are not the intended recipient= , please contact the sender and delete all copies; any review or distributi= on by others is strictly prohibited. From nobody Mon Sep 14 04:51:57 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) client-ip=38.145.34.151; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1788778284; cv=none; d=zohomail.com; s=zohoarc; b=UNn30JPRwoi4bqz4JlSTNcHfc8F/8zjgfZIzO/3wj2WUOTOa8hUU7WVbO62aiW/b9LuIHfZhk7BOptjn1OGhd++kfDfoudHVPbeSvnuMeQudWgAkvNkJkaYB5ZUPpb4xSzukiXLnZiEYeeO57ryLoPlcLj/jUCDiqtprr7BBTFI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788778284; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=Jx/zwGh2ihDMISZS1L4nYjIOXzMF30xgjyHm3arg7AU=; b=PcL6ONiSK+qAlxeRlBCHB4XiTR4ofWSG93vJIDBce7b4mIG8zljuBGqzO5+Md43K66GKbuaX0s0C06zQ+EOHWz0zOWEKKEzTBsKjvTKYEQpjXdtnCBFazy/QVvHnLY4OSofPiFeCnWUmLMexie4tk4p2JhZ5/yCyeG81ceF5SIc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [38.145.34.151]) by mx.zohomail.com with SMTPS id 1788778284169787.9966935564743; Mon, 7 Sep 2026 03:51:24 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 4453B418CD; Mon, 7 Sep 2026 06:51:22 -0400 (EDT) Received: from [172.19.199.13] (unknown [10.16.107.18]) by lists.libvirt.org (Postfix) with ESMTP id 044B3419A7 for ; Mon, 7 Sep 2026 06:46:48 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 10E2D3F2F4; Mon, 7 Sep 2026 06:46:25 -0400 (EDT) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 8613B3F362 for ; Mon, 7 Sep 2026 06:46:23 -0400 (EDT) Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2026 03:46:23 -0700 Received: from ubuntu.ger.corp.intel.com ([10.211.96.193]) by fmviesa007.fm.intel.com with ESMTP; 07 Sep 2026 03:46:21 -0700 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788777984; x=1820313984; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=e3JI+XF+2BAnsmo6d5m/FepfIyyzqMispy/AKMrSzWk=; b=depFflpiU596ITLC5Kk5uvUISTNPTx61hTeqgTRs+n8h5JuPDvhqpHCs 2jP9apw87KRJhOqSVuUMKrCVaNohbtEMsijmr6bs8XplZ3cZMr2RTDe+G Eb8sTpgtls8S/Lk78eYCVVkwbYsxgMN6cHadwAt9/0QgRXHk9LHgJxXcO H+v1uhwRrncqRJ6SWQYpRX469b4izKUz4T4nF2ij7DmeP7qOrahfq2PKB /nESZFOuvnFmmF+ek+VqasT/uV3Pq+1lETMgyiJn2rXsHkdqJtt9tGHCq HZZ9CZEf/EPPI2KvSvWpgaYyyC252CCYgHBW4//ZJ/VB5fknVQUDthJoU g==; X-CSE-ConnectionGUID: lpMXL+fhQKa63PE1N40ndg== X-CSE-MsgGUID: RvlBIoY9QSeDkNoSIoXL8w== X-IronPort-AV: E=McAfee;i="6800,10657,11898"; a="89109074" X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="89109074" X-CSE-ConnectionGUID: b4bWaY98Tcm2S+Q8+D0oww== X-CSE-MsgGUID: ZH4bmzqHTROAOt6wu/Nm7w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208";a="267431628" From: Jedrzej Wasiukiewicz To: devel@lists.libvirt.org Subject: [PATCH v2 4/4] qemu: omit vcpus for whole-process resctrl monitor stats Date: Mon, 7 Sep 2026 12:47:11 +0200 Message-ID: <20260907104711.2303928-5-jedrzej.wasiukiewicz@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> References: <20260907104711.2303928-1-jedrzej.wasiukiewicz@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: QQ5V4F3KWL3CGUCEB4RZ4VPQ6PPGAETK X-Message-ID-Hash: QQ5V4F3KWL3CGUCEB4RZ4VPQ6PPGAETK X-MailFrom: jedrzej.wasiukiewicz@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Christopher M . Cantalupo" , Michal Privoznik X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1788778287613154100 Content-Type: text/plain; charset="utf-8" Whole-process monitors have no vCPU list. Leave the collected vcpus value unset and omit the typed parameter for cache, memory bandwidth, and energy stats instead of reporting an empty string. Signed-off-by: Jedrzej Wasiukiewicz Reviewed-by: Christopher M. Cantalupo --- src/qemu/qemu_driver.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 8498568623..9159c769fe 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -17410,11 +17410,10 @@ qemuDomainGetResctrlMonData(virQEMUDriver *driver, =20 res =3D g_new0(virQEMUResctrlMonData, 1); =20 - /* If virBitmapFormat successfully returns an vcpu string, then - * res.vcpus is assigned with an memory space holding it, - * let this newly allocated memory buffer to be freed along wi= th - * the free of 'res' */ - res->vcpus =3D virBitmapFormat(domresmon->vcpus); + /* Leave res->vcpus NULL for a whole-process monitor; formatti= ng + * its empty bitmap would report an empty vcpus field. */ + if (!domresmon->whole_process) + res->vcpus =3D virBitmapFormat(domresmon->vcpus); res->name =3D virResctrlMonitorGetName(monitor); =20 if (virResctrlMonitorGetStats(monitor, (const char **)features, @@ -17464,8 +17463,9 @@ qemuDomainGetStatsMemoryBandwidth(virQEMUDriver *dr= iver, for (i =3D 0; i < nresdata; i++) { virTypedParamListAddString(params, resdata[i]->name, VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_MONIT= OR_PREFIX "%zu" VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NAME, i); - virTypedParamListAddString(params, resdata[i]->vcpus, - VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_MONIT= OR_PREFIX "%zu" VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_VCPUS, i); + if (resdata[i]->vcpus) + virTypedParamListAddString(params, resdata[i]->vcpus, + VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_M= ONITOR_PREFIX "%zu" VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_VCPUS,= i); virTypedParamListAddUInt(params, resdata[i]->nstats, VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_MONITOR= _PREFIX "%zu" VIR_DOMAIN_STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NODE_COUNT, = i); =20 @@ -17529,8 +17529,9 @@ qemuDomainGetStatsEnergy(virQEMUDriver *driver, =20 virTypedParamListAddString(params, resdata[i]->name, VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_PRE= FIX "%zu" VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_SUFFIX_NAME, i); - virTypedParamListAddString(params, resdata[i]->vcpus, - VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_PRE= FIX "%zu" VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_SUFFIX_VCPUS, i); + if (resdata[i]->vcpus) + virTypedParamListAddString(params, resdata[i]->vcpus, + VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR= _PREFIX "%zu" VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_SUFFIX_VCPUS, i); virTypedParamListAddUInt(params, resdata[i]->nstats, VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_PREFI= X "%zu" VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_SUFFIX_PKG_COUNT, i); =20 @@ -17586,8 +17587,9 @@ qemuDomainGetStatsCpuCache(virQEMUDriver *driver, for (i =3D 0; i < nresdata; i++) { virTypedParamListAddString(params, resdata[i]->name, VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_PREF= IX "%zu" VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_SUFFIX_NAME, i); - virTypedParamListAddString(params, resdata[i]->vcpus, - VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_PREF= IX "%zu" VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_SUFFIX_VCPUS, i); + if (resdata[i]->vcpus) + virTypedParamListAddString(params, resdata[i]->vcpus, + VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_= PREFIX "%zu" VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_SUFFIX_VCPUS, i); virTypedParamListAddUInt(params, resdata[i]->nstats, VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_PREFIX= "%zu" VIR_DOMAIN_STATS_CPU_CACHE_MONITOR_SUFFIX_BANK_COUNT, i); =20 --=20 2.43.0 --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydz= ial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-31= 6 | Kapital zakladowy 200.000 PLN. Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu usta= wy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w trans= akcjach handlowych. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata= i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wi= adomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiek= olwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). If you are not the intended recipient= , please contact the sender and delete all copies; any review or distributi= on by others is strictly prohibited.