From nobody Sun May 19 07:31:42 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1662388370; cv=none; d=zohomail.com; s=zohoarc; b=HpwZ9046xIzuaksRhcgOZ0lOz54rHbSzWCVl1Eu6RlB+DT/WduOgdQd5mBKEdV7kD3vhbjnV7bn/KqUoqM7dRQqb6DgC53lct97tgkjQqm6j4pRxy9OU14RQBwC8XveAJzuUFif72I98v3UlqzPHKGaENRXNKv7SPqkd5AtwQko= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1662388370; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=G4MOH/dzifTgN/X2IiQG/oAdCKODgaYa238s+61Y9WM=; b=XqcPW6zFG0y8KR5nFtwoGMJVGyT0s43rVm2wADF+CH4CgYj2JxqDgG0KMSF6p21hZYr7uFzthqj2EpVrP0KvBljxqrZKzOEbNuqSaGQJvBjPczDu1nPND8lWdY10w/fX6qcwJm0OuyCTUZO3HrgDF2Y2dDCVh0nii8sIQfl7tlM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 166238837026118.851702601770512; Mon, 5 Sep 2022 07:32:50 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-335-9nPRVPH1O3yO-S9nGnYLtA-1; Mon, 05 Sep 2022 10:32:43 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9562F3C02B75; Mon, 5 Sep 2022 14:32:41 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7BA842166B29; Mon, 5 Sep 2022 14:32:41 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 44F0E1946A48; Mon, 5 Sep 2022 14:32:41 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id D8CA41946A47 for ; Mon, 5 Sep 2022 14:32:39 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id BC3181415137; Mon, 5 Sep 2022 14:32:39 +0000 (UTC) Received: from maggie.redhat.com (unknown [10.43.2.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id 682A01415102 for ; Mon, 5 Sep 2022 14:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662388369; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=G4MOH/dzifTgN/X2IiQG/oAdCKODgaYa238s+61Y9WM=; b=bhJoz7Wp5PRyICqyw46OFBuQ4NkcSwL4b1KSqHktgpG47C9Ezq2bif3picCrX0Juzmg+nd Vg8G9xINcaVpDX5qZMwfbD15JQq+lmUJQj5MIaIYxOSGqI7eUrmZvEii1W1LD8ngmnREcN gMuiB7yV70vX3m06IOLRjKP4vmEhXHk= X-MC-Unique: 9nPRVPH1O3yO-S9nGnYLtA-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH 1/2] qemu_process: Don't require a hugetlbfs mount for memfd Date: Mon, 5 Sep 2022 16:32:28 +0200 Message-Id: <7ec6b469f2fdebad15e2bb1b12a2221b8957f4e4.1662387792.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1662388371889100003 Content-Type: text/plain; charset="utf-8"; x-default="true" The aim of qemuProcessNeedHugepagesPath() is to determine whether a hugetlbfs mount point is required for given domain (as in whether qemuBuildMemoryBackendProps() picks up memory-backend-file pointing to a hugetlbfs mount point). Well, when domain is configured to use memfd backend then that condition can never be true. Therefore, skip creating domain's private path under hugetlbfs mount points. Signed-off-by: Michal Privoznik Reviewed-by: Martin Kletzander --- src/qemu/qemu_process.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 32f03ff79a..8102e689fb 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3888,8 +3888,18 @@ qemuProcessNeedHugepagesPath(virDomainDef *def, const long system_pagesize =3D virGetSystemPageSizeKB(); size_t i; =20 - if (def->mem.source =3D=3D VIR_DOMAIN_MEMORY_SOURCE_FILE) + switch ((virDomainMemorySource)def->mem.source) { + case VIR_DOMAIN_MEMORY_SOURCE_FILE: + /* This needs a hugetlbfs mount. */ return true; + case VIR_DOMAIN_MEMORY_SOURCE_MEMFD: + /* memfd works without a hugetlbfs mount */ + return false; + case VIR_DOMAIN_MEMORY_SOURCE_NONE: + case VIR_DOMAIN_MEMORY_SOURCE_ANONYMOUS: + case VIR_DOMAIN_MEMORY_SOURCE_LAST: + break; + } =20 for (i =3D 0; i < def->mem.nhugepages; i++) { if (def->mem.hugepages[i].size !=3D system_pagesize) --=20 2.35.1 From nobody Sun May 19 07:31:42 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1662388367; cv=none; d=zohomail.com; s=zohoarc; b=O27v7p38EhWs7/v5M9+7XEMd/mkual+/Don8TPyNAoDY1aTCj6h458wcYdpBGBtva6qafn/bJGIOIcPSZHjW58UZ3c2sxBcCheDKxU4Vw/f5Yk4tRmEuuDHDua10OIak38iWO5D1k+GTQTMEPcuAz3I0TGu7I/xO3iCdmB2wj0I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1662388367; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=YKqm5weFYPLs5qzGj7QWsrgg4Z3yS/rPWmn2u/MSx1Q=; b=EZXQWrAmTcfVcgc3TuNHWKkDxk4yhoY6qmx3ER0Is/Aj2yMz4RZqkgWPUjOu0PIz7BVgwnGtrFtspDED4xxndujPnbRcswtKMD3Cp+wRtV74I315vGVmNZuwy//FjAVQcr0lMWr/p+E2G+jZFg//g5CaKXwU36ZBELBfOjaFkwo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 166238836794263.827513859818396; Mon, 5 Sep 2022 07:32:47 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-47-O29ve6RyO2Opy6z9_ckLqA-1; Mon, 05 Sep 2022 10:32:45 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3796280A0B7; Mon, 5 Sep 2022 14:32:43 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 23EA01415102; Mon, 5 Sep 2022 14:32:43 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id E96AA1946A48; Mon, 5 Sep 2022 14:32:42 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 6EFEC1946A47 for ; Mon, 5 Sep 2022 14:32:40 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 526AD1415102; Mon, 5 Sep 2022 14:32:40 +0000 (UTC) Received: from maggie.redhat.com (unknown [10.43.2.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id F265D1410F38 for ; Mon, 5 Sep 2022 14:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662388367; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=YKqm5weFYPLs5qzGj7QWsrgg4Z3yS/rPWmn2u/MSx1Q=; b=eCV+FQsrkpOuaJ5VJSnKSqARSCtXaqtThI5IVYn0xjfuLmvb2i9dz8JMcmfVoO8ol2NKlF rgQMz3q6V8K8vAM2Rmmsm/AACMCrOEjnypS8osijGMTk36pOz8VcyBxLWZhS1xh3yR0U1+ 2OdLaeg8pl/BX5w/gcamOime/GMMp5Y= X-MC-Unique: O29ve6RyO2Opy6z9_ckLqA-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH 2/2] kbase: Document QEMU private mount NS limitations Date: Mon, 5 Sep 2022 16:32:29 +0200 Message-Id: <70d19abac5f1390eb3d2061228a70d2ad204e076.1662387792.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1662388369909100001 Content-Type: text/plain; charset="utf-8"; x-default="true" There are two points I've taken for granted: 1) the mount points are set before starting a guest, 2) the / and its submounts are marked as shared, so that mount events propagate into child namespaces when assumption 1) is not held. But what's obvious to me might not be obvious to our users. Document these known limitations. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D2123196 Signed-off-by: Michal Privoznik Reviewed-by: Martin Kletzander --- docs/kbase/qemu-passthrough-security.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/docs/kbase/qemu-passthrough-security.rst b/docs/kbase/qemu-pas= sthrough-security.rst index 4381d9f3a6..106c3cc5b9 100644 --- a/docs/kbase/qemu-passthrough-security.rst +++ b/docs/kbase/qemu-passthrough-security.rst @@ -156,3 +156,25 @@ will affect all virtual machines. These settings are a= ll made in =20 * Cgroups - set ``cgroup_device_acl`` to include the desired device node, = or ``cgroup_controllers =3D [...]`` to exclude the ``devices`` controller. + +Private monunt namespace +---------------------------- + +As mentioned above, libvirt launches each QEMU process in its own ``mount`` +namespace. It's recommended that all mount points are set up prior startin= g any +guest. For cases when that can't be assured, mount points in the namespace= are +marked as slave so that mount events happening in the parent namespace are +propagated into this child namespace. But this may require an additional s= tep: +mounts in the parent namespace need to be marked as shared (if the distrib= ution +doesn't do that by default). This can be achieved by running the following +command before any guest is started: + +:: + + # mount --make-rshared / + +Another requirement for dynamic mount point propagation is to not place +``hugetlbfs`` mount points under ``/dev`` because these won't be propagate= d as +corresponding directories do not exist in the private namespace. Or just u= se +``memfd`` memory backend instead which does not require ``hugetlbfs`` mount +points. --=20 2.35.1