From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a1214a2aa3-cae4ae7d-a813-4a29-b468-d8c295276a0c-000000@eu-central-1.amazonses.com> Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazon11022143.outbound.protection.outlook.com [52.101.66.143]) by lore.virtuozzo.com (Postfix) with ESMTPS id 1DA3780726 for ; Fri, 9 Oct 2026 15:31:15 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=n0n0awNF2f1jy+6L4bguc89iDxY0HEJZFpqgblpqOknGlOVfecheaWc+GDNbyJfxDdCPFy4BAwg0RiKpwDeWquZbgmMHRgnl4JS4MbbNFHNP0ZQFTMHJkzwc0ixSp1GNWmIcJGuwVbsWWOYyahy9FeofR8Cg7ouuhgbnjXlPoj/mAg//L+2g/+8HdVvvjA+BGiUsIrMt25LNUWYIH+2bzT8gtw8hahNnB2d2Z4DIfY9TbQfr2JLFwMZ2MTmQ4qxDKz+mzhsb8JLB4GjcA65q9bAzWqwDd+U18ydYUqJ5PNyJ/+URtRJQLGz4q6TQMWNbcHywlvHWUoIypFMmRgvZrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bULfwuaCsW4HQxlVPqe/1R/qYnSf1WzbODhBBx7HEFM=; b=Se0/wnXGibEfPP3eGzUPiNmhS2TFoUadJFQi5+c72PFa3JDGMTk5cL35NpaC7I+Ros07QkeZBSeqNb41Q/WTAdZxnut7SD1idkgzhRBARAO+hpN+wJ2OWsIq1Dv+BhO3N5MPR4bsvtzNLKIe2BWWGHOAABXvKb9JmAXVfnoa/EB8TX3mlQ8YoeNWccceg935za+R+DPm/eFb7D3uVnClg2+81DI63RNiZwiFWSe14cSoZvr3LFB6IxgLifPbtvF+g0+Jkte4nM6PZJO2Ysf6a80gmwArlZgnsF/xuxfQT2vt7bLB4QP6LSvNYIzBrFqWAlXTFJURNAAbUGdqSoQJjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bULfwuaCsW4HQxlVPqe/1R/qYnSf1WzbODhBBx7HEFM=; b=Vw5ll+I7Fr+JZxmrZ/t2T20wIfa78hQGz2zBgmnpH5RHDj1fmvlpgSdbx8PmNiaCAZCtOJj3+HG1ElNqjyeNKUvczPEftDhjphj3dFL9IUIhuh8oZeNC8L3w+OzNY/Q/0Iawx/P5NJyTh13HUxWY2mgi0am85o/C+6oBMfJTax4= Received: from DUZPR01CA0067.eurprd01.prod.exchangelabs.com (2603:10a6:10:3c2::6) by MI9PR08MB999927.eurprd08.prod.outlook.com (2603:10a6:290:8b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6; Fri, 9 Oct 2026 15:31:12 +0000 Received: from MAD0EPF000008AB.eurprd04.prod.outlook.com (2603:10a6:10:3c2:cafe::1e) by DUZPR01CA0067.outlook.office365.com (2603:10a6:10:3c2::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Fri, 9 Oct 2026 15:31:12 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by MAD0EPF000008AB.mail.protection.outlook.com (10.167.241.183) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Fri, 9 Oct 2026 15:31:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791559871; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=dn6c8IIAbJZaJ6N19zbP7dR2l8pG3xTk1WwsbHZiGBY=; b=oicIkDSU1goXsbgpXmYOKgw03luLM7BcaV7hit7IEwCtkuYP3/PsfvXDVntIhycP QtFMh8S0z1e8omGafFtzhQyjJlueGzbVSVefPUUvs1PN21FOuDv4LKC0bxzoq53D10I by+Eg5bGqFSwJw91jlXZwnr2w1zddz5UQI2eXKoEtGyWGPMJjgDfXFHopA86ds1B6mO oatKwuSW9Y3Mw6JTXONQBa/LLzvhve7DgvqIkc8Te1vfatCcYGYi0ywNr9fIw0Yod4P twbxlrT3fGwC7tzGLhkE3z7H4UC3NDEwXnbKNP0q7Z0L3pouqVkiBT/XQCxcxvRvPoj vUEosy4IEA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791559871; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=dn6c8IIAbJZaJ6N19zbP7dR2l8pG3xTk1WwsbHZiGBY=; b=nHONd92jO9r1jtxzhPfz09J6bS7xmdXpKeOPmXi79rGh5nCLkgKvnVFaFpCuLNIP SpuEbO+Hq4KhE8Z0aAxnovjUPU2MuxvNZfXTWBSL7yU3mPyITg2X4uJpQFuU+UQlf0I SOf+eURpkf/KRn3Zu4rAjmJ1Uth2McaZPkWaYquw= Message-ID: <010701a1214a2aa3-cae4ae7d-a813-4a29-b468-d8c295276a0c-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 18/21] VZ: physmem: align fd-backed RAM like anonymous RAM #VSTOR-103860 To: svt-core@virtuozzo.com, Andrey Drobyshev In-Reply-To: <20261009-vfio_v1-v1-18-2ae91d5b8048@virtuozzo.com> References: <20261009-vfio_v1-v1-0-2ae91d5b8048@virtuozzo.com> <20261009-vfio_v1-v1-18-2ae91d5b8048@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Oct 2026 15:31:11 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.09-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MAD0EPF000008AB:EE_|MI9PR08MB999927:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bf0259fd-d56a-43e5-5b51-08df261a593a X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|48200799018|376014|61400799027|32142699015|9140799003|55112099003|56012099006|5063699009|5023799004|4143699003|16102099003|10067099003|18002099003|22082099003|6133799003|5113699003|4113699003|3023799007; X-Microsoft-Antispam-Message-Info: eXJEEu9mXbkTXHlP0mLq4Dm2MaFGIqW4J1AEVkgzEubFtM5226D1Cin00qh9Pb7BoOFJ6ows3N6sX27fBORpgthGKPVZ/3HNydqduWetpsoR6Y1SU8aTskWTb1CR2nt7ThVfataasVLYrm7f8pvIyiFJijMwf9G/NyA3A5Tsz0DV6rzq2/5cFnul8Gd7H3h8yRwDn9WU5fSnmInCS6lJMBciXnbwLnYMb9s6jnTmf/GaWjA6pX6PjSiTc1gXPr0YOx7AzF+USZjaBbeaErY+F7xl1GB4b5mzg/JfGhpKvj4daS5QB472k7hsR2atVA6dMQfTyRCdai1YOpvQ9+kgPq3F+3i+Kdg1Hx96ruFdVIr6X0Ljl7NUHznBmPoRtcv2AszOFmQHSZ6Vuq5CsIf6yObh0kHH1kpwSZ8AWtXkGPLotHiOmHg4kWWuaq6R+XHr3mCHLD9U6UX/dGPBhC8RfFaZfqYOY/ls7IESFn/6WR7WVRRHOtFlmN/wE0cSjGkOIccva4sJ7OzkpH4f4mh4XQ8TXzq0jTYFgQgzlr3yyPxBOkNyH7CoSTjye2ZOv1i0YQSXFOlVS+p4l3TW8oePlnj/AS5MlesXqfAhctfiIaH4fmGPKmXxp8tV/MVFqWDcZ9O9fmMpxA1lIq8PhmJ2hG2uxcmddhMOaOniYQWBpFYxCuAlyrrTZkUTn6VHzzRs6cnQabEobyn+Op3xylFMnLpEapldIRKrEvAfLd3C+qobgEYqVCrTKC0arhCa4bB8S1i1KPA6Mf7vOijrImcmBN1i2shH25SxtCKi0JMsa77je0NEA5hZiQ9pAGvQdT7j X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(48200799018)(376014)(61400799027)(32142699015)(9140799003)(55112099003)(56012099006)(5063699009)(5023799004)(4143699003)(16102099003)(10067099003)(18002099003)(22082099003)(6133799003)(5113699003)(4113699003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 10cqwgNneugTVP0mLqsUv7QqHNBQYJ43dbzWbc7ia6XO8iDP2q5lEAr5npDHC/ksb8Ovvr2KimNmZG5lV1KiPlZ3FiLCi6mWX63lAhKGBTiNJOqm774uI0mU0vHBHvbtW5DoDJ78YqeGyH3hlqSOYkfeT1eoT5UTyD6I6NapGRpo1tl9gp3o8AS2GSMC02s7vL6uvfkbLjTAOl4xNrBoSJMGiPFVxsjFsyPf4jHbhEmI6Z1YyUDSfI7/1nxmztSp2ZJhHXoT3S/8+Ptm8oJa0upGzUVdTtw6nBQYlqylpIeYKJTDTNrbIKjyR7it3KCZa/NuqmUNk4Nryg1mRZv73+vxm74YboTBV2NoWmcLT6kfcw9owW9zF3ycund0Bo89m/isg/x9tMObsmMrvG9xL4Zti9Z0GIFrg/al6bauIcVtzzspw15t+GVRaaWaTG7i X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 15:31:11.6822 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bf0259fd-d56a-43e5-5b51-08df261a593a X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008AB.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: MI9PR08MB999927 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] physmem: file_ram_alloc() raises shared mr->align to 2M for all = fd RAM, with no compat - [Medium] physmem: 2M alignment for fd-backed RAM shrinks NVDIMM PMEM size - [Medium] physmem: 2M align forced on all fd-backed RAM, incl. non-shmem f= iles and offsets -- commit 06425618e51a0375322bf7c00e7205bad272313c Author: Andrey Drobyshev VZ: physmem: align fd-backed RAM like anonymous RAM #VSTOR-103860 This commit raises the alignment of fd-backed RAM blocks in file_ram_alloc() to QEMU_VMALLOC_ALIGN on all hosts, instead of only on s390x KVM. The goal is to make memfd and tmpfs backed guest RAM eligible for 2M transparent huge pages. > diff --git a/system/physmem.c b/system/physmem.c > index 6f89232d257f..ae5aa534c60a 100644 > --- a/system/physmem.c > +++ b/system/physmem.c > @@ -1476,11 +1476,14 @@ static void *file_ram_alloc(RAMBlock *block, > return NULL; > } > block->mr->align =3D MAX(block->page_size, block->mr->align); > -#if defined(__s390x__) > - if (kvm_enabled()) { > - block->mr->align =3D MAX(block->mr->align, QEMU_VMALLOC_ALIGN); > - } > -#endif > + > + /* > + * Align like anonymous RAM (qemu_anon_ram_alloc), so that shmem-bac= ked > + * RAM (memfd, tmpfs files) is eligible for THP. > + * > + * On s390x KVM this alignment is required. > + */ > + block->mr->align =3D MAX(block->mr->align, QEMU_VMALLOC_ALIGN); [Severity: Medium] Can this unconditional bump of block->mr->align reject configurations that were accepted before? mr->align is the same field returned by memory_region_get_alignment(), so it is not only an mmap alignment. memory_device_pre_plug() checks it against the backend size: hw/mem/memory-device.c:memory_device_pre_plug() { ... if (!QEMU_IS_ALIGNED(memory_region_size(mr), memory_region_get_alignment(mr))) { error_setg(errp, "backend memory size must be multiple of 0x%" ... } A memory-backend-file or memfd backend (not hugetlbfs) used with pc-dimm, virtio-mem, nvdimm or hv-balloon, whose size is a 4K multiple but not a 2M multiple, was accepted before. Would it now fail at plug time with "backend memory size must be multiple of 0x200000"? The same function also does: align =3D MAX(align, memory_region_get_alignment(mr)); and passes it to memory_device_get_free_addr(). Can this change the auto-assigned guest-physical address of file-backed DIMMs once earlier devices have odd sizes, or trigger the "memory fragmented due to alignments" error? virtio_mem_device_realize() (vmem->mr->align =3D memory_region_get_alignment(&vmem->memdev->mr)) and hv-balloon inherit the larger alignment as well. No compat property or machine-type gating is added, and the commit message does not mention these side effects. Is that intended? [Severity: Medium] Can this change shrink the guest-visible NVDIMM size, or make realize fail, for file-backed NVDIMM backends? hw/mem/nvdimm.c:nvdimm_prepare_memory_region() { ... align =3D memory_region_get_alignment(mr); ... pmem_size =3D QEMU_ALIGN_DOWN(pmem_size, align); if (size <=3D nvdimm->label_size || !pmem_size) { ... nvdimm->nvdimm_mr->align =3D align; } With align now 2M instead of 4K, a 1G backend with a 128K label would expose 1G-2M rather than 1G-128K. A backend smaller than label plus 2M would hit the "too small to contain nvdimm label and aligned PMEM" error. The 2M alignment is also carried into nvdimm_mr->align and so into later memory device placement. Could this break migration or compatibility with guests expecting the old size? The commit message only discusses memfd and THP and does not address NVDIMM sizing. [Severity: Medium] The commit message and comment justify this change for shmem-backed RAM (memfd, tmpfs), but the bump applies to every fd, including regular files, DAX/pmem files, and memory-backend-file with an offset. Should it be limited to the shmem case? Non-shmem fds gain nothing from the larger alignment, yet qemu_ram_mmap() now reserves size + align of address space for them: util/mmap-alloc.c:qemu_ram_mmap() { total =3D size + align; ... offset =3D QEMU_ALIGN_UP((uintptr_t)guardptr, align) - (uintptr_t)guard= ptr; ptr =3D mmap_activate(guardptr + offset, size, fd, qemu_map_flags, map_offset); ... } Also, only the virtual address is aligned here. The file offset is passed unchanged as map_offset, and file_ram_alloc() only requires the offset to be a multiple of page_size: area =3D qemu_ram_mmap(fd, memory, block->mr->align, qemu_map_flags, of= fset); A PMD mapping needs the virtual address and file offset to be congruent modulo 2M. With a memory-backend-file offset that is a 4K multiple but not a 2M multiple, would this alignment still give no THP benefit? Downstream, the memory_device_pre_plug() size check and the nvdimm_prepare_memory_region() QEMU_ALIGN_DOWN(pmem_size, align) now apply 2M constraints to these file-backed regions as well. > =20 > if (memory < block->page_size) { > error_setg(errp, "memory size 0x" RAM_ADDR_FMT " must be equal t= o " --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261009-vfio= _v1-v1-0-2ae91d5b8048@virtuozzo.com?part=3D18