From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id 0755C8017D for ; Fri, 16 Oct 2026 12:59:24 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69GCw0UV016799; Fri, 16 Oct 2026 15:58:01 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69GCw0UV016799 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="V4Hwy0Co" Received: from mail-yx1-f69.google.com (mail-yx1-f69.google.com [74.125.224.69]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69GCvwM3016794 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 16 Oct 2026 15:57:58 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69GCvwM3016794 Received: by mail-yx1-f69.google.com with SMTP id 956f58d0204a3-679b648598bso793019d50.1 for ; Fri, 16 Oct 2026 05:57:58 -0700 (PDT) X-Gm-Message-State: AFq9FYJz7k+MG0P9fdOynkK7xwz708AyUxMRrBDEluelzqeNhwfZOTtv 0ONniGIu1G2jf5y/NyMRuX3PmfwsWCZlKceb0pDpnDj7mG2O+eQ99g0dwtC3dS9g+s4kqQ6jMSu eGbVqYJmxwkmuWrHpsFsVEGONQHuueMbtUMfbfEFnlsId3ScCkX2emQ== X-Gm-Gg: AYBFou01c14y+I7PM4w65+cMJrWpOolaUvIUmdb9/0prhZaPn7ox/rkDw9FrqOym4zP 3wJZg8W0VLjkuxvjO9KbQqYXsvVafcxQOoM5hXECrsgPmY61X5drfQb0D2QiOTb5T+TBaioktmZ XMiU3GMHb5B5Kb8w/cQlX26WCMWJIbO+a928qfUxD7wPaBkOaMtyfhVsWRuTN2XKc4tBHeTfeuN M1CQcNCYvdqcJXvwG8nkks6YEgkRmVXrIWtn9t0ttko/Ymi+fm2F3HrFK8cMuVufptDhuyHK1rL aWEBpJkTCjFD2dGd4neCe5xIzRNZN7+lyJGxZj4N8e4i6AGlYNcRD9t959aIuD+MAwFzPanIhXC PWOb2YzduSAEY2tbPa3Ii70teld88IUUYwzzO10I7X6eyI8N4YZy6CMXBlj96mk4/76BSdwNK1o TpZIghm9LMf7tElB2sCUpfK6zM2Z14cnk= X-Received: by 2002:a05:690e:168b:b0:677:d251:cce5 with SMTP id 956f58d0204a3-6793602668emr9940175d50.43.1792155477494; Fri, 16 Oct 2026 05:57:57 -0700 (PDT) X-Received: by 2002:a05:690e:168b:b0:677:d251:cce5 with SMTP id 956f58d0204a3-6793602668emr9940165d50.43.1792155476815; Fri, 16 Oct 2026 05:57:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1792155476; cv=pass; d=google.com; s=arc-20260327; b=SW4TXeTJb5Zo6wPbyLxbaky5uyrigMYVKHgBzkYqnGePK6CwhLE+oNUTvH/eG8n//v 1NLxs+f5Ejqk/G5/ZopCVpmszaFy+EbE0UDOq7YqSVSSx8uHjhP0FQWZEC8ergAN6Naf TYgBUdl5SXZyjRfdBzdA08wMTvBK22ThfWC1u2kOrWJBgemwf8nPZvNCnhKsUepIRnYH 2cgqQHXTreB08HEw9jarq0zPusF3h27Zi+TnHdv/wwXfp3Nq3kjsXsCs3hz0dI1Fu9ZF YGnea3CWQ1F3zm7UCZ+FIBn1rYQCs6muwsbrwvCjoYcM87PocswEE3r4G4mFG3yFLWkG U0CA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:date :message-id:dkim-signature; bh=o5DnK6iADaoF6JhBfp/qONN2Fa+/7+t8hFP7N9Mso1c=; fh=rlm5iAWUwP1WXt/SUvBbvj4jUiIP7I0vRU4U7/jH5Ik=; b=I8lav5oRmOTSOw7YzvufdGNBDysoMYZ71oeDziVQ9NE9kyzjI4cUQ1jgu0S7Uj8bmN OQgf2MxGPn4J6zqc0D9qeL74Pu2RdZHkAoaLHoguGKpiOpMH+vTXcmeeGjdXR2Ot4QOL mgb6TW5V/yC74HD/VqZh5IHvG/V+c6QlwhZmysaCgZy6naAo14UJB9gtTrcM5Ox+Oj6v dMEc36SY69ssN+y542S5qZhFrRxn+zQiB+YclCSPtI2/i77ukSpTpY4wA75xNZx+P6OX xHbTA00Yj4VKisqmPtPfLLA/pdroY9EdqFlFunckgAdL08mLgIDoZnsW4q9WeZH4mli6 QHdA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=V4Hwy0Co; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of andrey.drobyshev@virtuozzo.com designates 2a01:111:f403:c201::1 as permitted sender) smtp.mailfrom=andrey.drobyshev@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazlp170100001.outbound.protection.outlook.com. [2a01:111:f403:c201::1]) by mx.google.com with ESMTPS id 956f58d0204a3-679b205a715si1051157d50.248.2026.10.16.05.57.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Oct 2026 05:57:56 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.drobyshev@virtuozzo.com designates 2a01:111:f403:c201::1 as permitted sender) client-ip=2a01:111:f403:c201::1; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=V4Hwy0Co; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of andrey.drobyshev@virtuozzo.com designates 2a01:111:f403:c201::1 as permitted sender) smtp.mailfrom=andrey.drobyshev@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IThgozR4rLSAWKMiO0Ip2+Bs64Beq5l2im+ToMkScpobv6pCtUe64a0lNNMQMalZh5qI5S/mka91yZCOtrTsTITSSZVBvo+XQInQSAw7l+6mzbebMBAbc/3Aj+vCPfmfWGNTh1yNA/FMoozWIK13Yu+DVkwg/Fn32lbDlybhGWHXcpikeLANYWbaqsN4JKqx7IaFc5wTih5rQzWNRb1jPn9XJvVE091E9X9lAvHHqKUYzUkSVyK6T1GgRzVx+0WN+ZeA2McIr2X0LeUIDxfo8W5mLwcIRElJMfQ3Y/GmPGsVm8nJMh3+3aQAkMYaEpZ2HQ3PssbnfqmGwT6uQOIS3w== 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=o5DnK6iADaoF6JhBfp/qONN2Fa+/7+t8hFP7N9Mso1c=; b=F57JjtQ8TEk/gC7S7TBykMbKRw7RilmniVlQkoFats0deBJzezwc9rcIB8KThQthD3d7Mqt/bbkcYW5lXDEAiI9KXx5h4Hmx4tPzyQXORNbGS61Ru0aw+MTIBd5KUHnnSsk6MlupS3iF+T7d9d97DqkPism7HJjCMj1oZigMHAhYmAhNB94tvp000Sbxy8pZNLjb6Jh7G32oPoPImqGMB4nHZask/Xo7Ta2mPy0Vo+L2sYr7kq8I9CKACOu9QR79T7b7IvbPPVldDzHyZGYi7P5Wz+axpOPcYLO/47YskG/676Ik14L87UmJlFPh64lXWp2u4Hr7cdfzQEzTMrsJrw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o5DnK6iADaoF6JhBfp/qONN2Fa+/7+t8hFP7N9Mso1c=; b=V4Hwy0CoqLaR2RorIxyfDqKhJOZnbkMbqEjwhw/TFaj2ltk0KofWWh2/zemv7qoDd4Tm6dBKSoJ0yIJlDqTfaHpmjZ9Cq0AjDHK+dTLf3zeQFNHyLIZLB2D3kWm5dquL4mOtguVzZD9Ezl/+sE9glxLBy1jeIOzD2J+0SsXcvzdZvRp1Ngm+p5g/DnrYmidoa4SfxPs3bRX2TqRN4daHCu2tKvvXGd8lkgv8Hdl8adG7AE3vRMbOJnTUx8zQDMjwy1D1M5I/sxYypdpk+fETqPuSIDRTElmZpuDXqnKOOk3D4CmgeOANwSim9ZOk9rCyjrQmuhgsTzrFDIKPuJYItQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from VI0PR08MB10656.eurprd08.prod.outlook.com (2603:10a6:800:20a::12) by MMZPR08MB912510.eurprd08.prod.outlook.com (2603:10a6:190:59::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.9; Fri, 16 Oct 2026 12:57:52 +0000 Received: from VI0PR08MB10656.eurprd08.prod.outlook.com ([fe80::4e37:b189:ddcd:3dd8]) by VI0PR08MB10656.eurprd08.prod.outlook.com ([fe80::4e37:b189:ddcd:3dd8%7]) with mapi id 15.21.0546.006; Fri, 16 Oct 2026 12:57:52 +0000 Message-ID: <61fe3d17-c8b9-4a01-b3b1-b5d2cda767f1@virtuozzo.com> Date: Fri, 16 Oct 2026 15:57:50 +0300 User-Agent: Mozilla Thunderbird To: Konstantin Khorenko , Vasileios Almpanis , Pavel Tikhomirov References: <20261014-b4-prep-khorenko-vstor-103860-4-doexec-vfio-bars-v1-0-7be6c4d68114@virtuozzo.com> <20261014-b4-prep-khorenko-vstor-103860-4-doexec-vfio-bars-v1-1-7be6c4d68114@virtuozzo.com> Content-Language: en-US From: Andrey Drobyshev In-Reply-To: <20261014-b4-prep-khorenko-vstor-103860-4-doexec-vfio-bars-v1-1-7be6c4d68114@virtuozzo.com> X-ClientProxiedBy: ZR2P278CA0010.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:50::14) To VI0PR08MB10656.eurprd08.prod.outlook.com (2603:10a6:800:20a::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI0PR08MB10656:EE_|MMZPR08MB912510:EE_ X-MS-Office365-Filtering-Correlation-Id: 4224dd0a-4a6a-43d4-5b7d-08df2b85167d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|376014|1800799024|23010399003|10067099003|22082099003|18002099003|4143699003|5023799004|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: FOMWeInkR6jPvoXFShxb1eFaVZ0k42qc/zQrWw7fVF0oCgB281Whnzt3KiCdyHv9YcaHR96pUFowVUUJS7fRRYH9YN9/CciveEjXDgS2mlVeduSCjQR3fmbRC7yw/nqCVMeHpUl86OZgKIMlm2ZxTmZLOFUZivj1I+uFrvj/CgO5RCHULSVhoE+HnKhKvZtEcx6I90wlqOzFWfYCnM2ObFx5q9mCWsTr9II1tRUIqWc9OC2Lzei7DPrFLKn3kU6fdGkCOd+J5A5B1ScpnKixeqmuiMmC1lFV88sfHe+Kcn0+UmiljNMvs9+ud6JT305aIuk40MWjGczARZ9k4EqV0hQKa19LhbDW8NuqS0MmoWhuoKG9GReofXFwFeVF21tAqX/IkkE3FAHgXhwA7IRsQGpzwNpfm9Lzu3YGhUYWY919ekHAaldnpvqjfM5/9FrSdhz+dOt2b/2E50kPbU/U78BljsT8RkMY+BkFl+9ct8QBXfEwK6Up2an9RH35v1Nfm8yiWWyVn19D0JO7+uZXwbsoxymteBcMrMequNb201Jg3O6Sy7rXL6zhy9GCGDw0e9uGBUHrdhU36PIGvO63E8b0/2CAtouSAd67XMPLGYLGdGcDJa5oaB/wOrvTZKgZW6K5+Kxf8iihVbIuUBozsFJJFYzIQ9fMxoaClolIiic= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI0PR08MB10656.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(10067099003)(22082099003)(18002099003)(4143699003)(5023799004)(261009223027099003)(56012099006); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aTRyVnlCdncram5UczZjU0poL0NrWXMyNkpqeWRyTHhuNktPQ3FlWkhLUlhD?= =?utf-8?B?S25jc2plYmxXZVVFYkQzRkJURWRqcDJKUE0raGYzaWZEQXBCZ0ljajZJRllU?= =?utf-8?B?a3FnRnlvSklpc3lkU096dC9NdklxOHpFNU5DeUozc2ExM1BJRHhHY25VNk5G?= =?utf-8?B?TEV2WWZESEI1N3YxSGNGOE1DbUhPd0s2QjRJZHFEUGg5QnZiUVY3QklzVWoy?= =?utf-8?B?V3o1eG9zbUNVMFFJQVJJeTg2dTArSk9wek9oUFdnY0dld1RPZ2c2ZkN0Ujlj?= =?utf-8?B?TlIySVg3ZlNNbDVRVVJHdHJMTFNXWmxOL3FyMVlWbTludlpCWSsxd1l1SUlB?= =?utf-8?B?dnNBSkFEa3liZ3FpQ3gvb1BlZjM2ZUVGdHROTmovYlJKb2xMQ20xTWI0VHJp?= =?utf-8?B?RUF0OXNPRG51UDhDOXJkRHMvckZDRGVIdHBKeUgyckNXVnRZQlZ1Ym5lMnB4?= =?utf-8?B?UXE1TDBTS2E0WURYa2FSSUdqZ2xhNTRiZnZFOXV0RForS0Z3QXdFNlNxeTBN?= =?utf-8?B?ckJTQ01lcFJwUDVNZWtRdURENFVOM1Nlem5ERUh2YVhIdHpUTk9vQzlnQ1RC?= =?utf-8?B?cmtubTd6aXYyczZxY2dRV3BqcEZlYStkVEErelNsNUJqdzF4c29HSGgvbDky?= =?utf-8?B?S29iVVFGZk55YUMvUERzdlNPSVl1TlRDZk1TY2w2ZDh6dXhybEJVbXJ5VXZU?= =?utf-8?B?dmxKQ0xuUTVLbC9jb0tsZ3lyc0FrYURneVJiNmxsQ0I3QXJ6THVIemkyRjhi?= =?utf-8?B?OUFMaURXeWloTVFtTWZkOGxrYnBkbEdvK3hDUkJGd3A4bE1KRWlHVENuOTN6?= =?utf-8?B?MElST2l1OFlPVjJFUyttSG5WZ09DdEhCZDBxTU9ienNBZ0Yxa1hPLzBjNXVL?= =?utf-8?B?bk0wb2pBcGpVdlprczJ5ZnhhVFRta3BSaEJYejBQSE1NR1h4ZUFNQkVSRGE0?= =?utf-8?B?K3RPdkd6NjczVHpoc2tEU1JzeDR2WTQvMDdQR3hWVzFGUHlMeHFndlRyMnFZ?= =?utf-8?B?RFRVN3pOUTkvZlMyaWlFekoxOHdtb0Z1OU5jTm1BYzdHRGZRYnZlSTZSSG8r?= =?utf-8?B?aWoycXB6U3ZaUW0yUnkvcHcwTUg3ckg2ODdjNTdNWVpENzdydHRlenA2SnZC?= =?utf-8?B?VG8vOEx5S1l5MW8yV1J6UWNocHNDdHZXV1ZybUxzNVRtR2p1RDI4dEpIcmM2?= =?utf-8?B?WXUyR2hranp3NGNCS3dVamhnaTFrNEVodUllcWFRdnpqK0szYk0xRWV5Z25O?= =?utf-8?B?MXdOT1dUVE4wUTh4UWtwaEsvb0ZxTUlBMnZpQ0paQUxVSTF1TUxLa1NMbDZn?= =?utf-8?B?VlhyWU1saUV4ZElzS1VpRFBmTnJOVlBJanpqNGVEMVpRQ1pyYVo4OWZyUWZV?= =?utf-8?B?L0tCY2lSeE5TN0V5bkpjTFpGakg2VDFEdmdpRm50bEoxQi9sTDVPZXlIUkk5?= =?utf-8?B?UFdHb1NjSFY5QWxqTHNWODJ2bzNlZjhwWEZ5bndJOGhJckV5RStOcVo0Ni9a?= =?utf-8?B?S29GSXFLZDVlSy9oVkhQSTNHZGRXYlpmTVVaSFo4UStsNzl5VWdlUWM4Nk01?= =?utf-8?B?WlB0bW8zUFoxcXNVTGdlRHZNa2FGVTZwbGo1alFkVTZxK0lqY2VhV2YzdUpN?= =?utf-8?B?SlgycXppak9aTHVFSEdEdHNhMmVYT2JBcklGTkkzK09GREp0dnhHMkNGb0ZL?= =?utf-8?B?U0JzL0NsQU5HUkVlU2NWWm9HNkh5TGZvUVVXV200emc4SEhoUHZJS2xBcDZz?= =?utf-8?B?bXE2ZGtzeVA0dFJjL3l1WWZ5eGZ0TVQ5STN6OS9FTkxkcHJUVC8yS1kydzlO?= =?utf-8?B?YTlza2xpeUIwY3VXTDMvanAraTk2VzRBM0RtdldpTVdWRkx6WWdTOXFpOFBS?= =?utf-8?B?WFpJMzBjRlhxWGRHUTg5QXR2ZjYzQzZNZmVxMWdGRmJaamVTbzE4ZzQwL3VT?= =?utf-8?B?ancyZWdNM2VteFdJYU1nYWNFK1BsOElya3Y0elh6ekNMcG1lZmQxODZKcU81?= =?utf-8?B?TjljL2ZnSVQyck1WWkttMk5Bd3VWU3pIa0hwaHFURUdGaEJESWdkL2pJTkhm?= =?utf-8?B?emtJbUFqRExqeVZicnM4WU83R1A5K24vMXVaRUFkMno1MlFUV0NqNTdWb1Qr?= =?utf-8?B?V1VQc0tvK2RvSjRxK202QzBOcnBtK0w4RytwRzlQOTZpemJFUVkxWVY2ajA0?= =?utf-8?B?VnVNb01GaFY3UFdMNHMwVjYyeVQ3YitzNjNONjkvRWErS2pQSFF4MzEydTBz?= =?utf-8?B?MGNKOFp2TUF0YWJia3drd1lndkRCelE1WXJZdlE1blBUWk1uWWlQdDY1c2Zi?= =?utf-8?B?KzlNcjdUQUY5Z0RidWFRS2xzNDQwUmZVYmtGaDFYNFF2ZlpPdHRjSTBSMzdS?= =?utf-8?Q?rAmeVRpaUhCjhomE=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4224dd0a-4a6a-43d4-5b7d-08df2b85167d X-MS-Exchange-CrossTenant-AuthSource: VI0PR08MB10656.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 12:57:51.9850 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FSLMCDYsHKjl540FRecUruxiGfD5HGneCmeOGJM/wq+UXvmzwf7DcunM2ZomsbhyB1H87fDyI/UNF/C9fNKZKeLp2FeeuCBTfoqz6Z2aNmU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MMZPR08MB912510 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 1/2] mm: allow MADV_DOEXEC on shared PFN mappings of device memory X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org On 10/14/26 8:14 PM, Konstantin Khorenko wrote: > From: Andrey Drobyshev > > QEMU live update (cpr-exec) keeps guest RAM across exec with MADV_DOEXEC, > but VFIO device BARs mapped into QEMU are lost on exec, and the new QEMU > has to mmap them again on the same device fd. > > Some drivers don't allow that. The NVIDIA vGPU VFIO driver records each > BAR mapping and refuses an overlapping one with -EINVAL. For VF BARs the > record is dropped only when the device fd is closed, so after exec the > new QEMU can't map BAR1/BAR3 and the vGPU becomes unusable. > > Let MADV_DOEXEC also preserve shared VM_PFNMAP mappings of a VFIO device > file, the BARs. vma_dup() duplicates them the way dup_mmap() duplicates a > shared file mapping: clear the inherited VM_PAT so that track_pfn_copy() > reserves the memtype for the copy, fork the anon_vma if the old VMA > ever got one, link the VMA into the file's i_mmap (so > unmap_mapping_range() on device reset still reaches it), call > vm_ops->open() and copy the special PTEs with copy_page_range(). > vma_link() places the copy after the original in i_mmap, since an equal > key goes right in the interval tree, which is the order dup_mmap() gets > from vma_interval_tree_insert_after(). > > Admit only a VFIO file, checked with vfio_file_is_valid() as KVM does; > of those only a device file can be mapped. Other drivers keep per-mm > state in such mappings and rely on VM_DONTCOPY to keep fork away: perf > charges a ring buffer to the mm's pinned_vm, so a copy would drive the > counter of the new mm negative and lift RLIMIT_MEMLOCK, and Xen privcmd > frees per-mapping state in ->close() without an ->open(). VM_DONTCOPY > itself cannot be the test, because QEMU marks every RAM block > MADV_DONTFORK, VFIO BARs included. A VFIO mapping whose vm_ops has > ->close() but no ->open() is refused as well, since the copy would run > ->close() a second time. > > No in-tree VFIO driver keeps per-VMA state, and the vfio-pci family > revokes BAR mappings through the device file's mapping, which reaches > the copy. An out-of-tree driver that tracks its mappings has to count > the copy in ->open(). One that maps with remap_pfn_range(), which sets > VM_PAT, and revokes with unmap_mapping_range() inherits the windows fork > has between track_pfn_copy() and a concurrent zap, and the one munmap has > between the zap of the old VMA and a device reset; no in-tree VFIO > driver does both. > > Dropping the mark gives VM_MAYEXEC back only to anonymous memory, where > do_mmap() decides it. A marked PFN map does not get it back, since there > the driver had the last word. > > Once the copy is in i_mmap, a zap from a device reset may clear VM_PAT > of either VMA holding only i_mmap_rwsem. So clear VM_EXEC_KEEP of the > copy before linking it, and touch VM_ACCOUNT of the old VMA only when it > is set. The source VMA is write-locked explicitly, as in dup_mmap(), > instead of through that vm_flags_clear(). > > Such a VMA may have NULL vm_ops, in which case vma_is_anonymous() > returns true for it. So the new vma_is_shared_pfnmap() helper is checked > first, also in zap_vma_mt(), whose threaded path for anonymous memory > would skip untrack_pfn(). > > https://virtuozzo.atlassian.net/browse/VSTOR-150233 > Signed-off-by: Andrey Drobyshev > Feature: oracle/mm: MADV_DOEXEC madvise() flag > (cherry picked from commit f1903df83b065cd59ebe30cfcf5fde6391fcc4e3) > > Changes while porting: added the untrack_pfn_clear() call, the > unconditional anon_vma_fork(), the VFIO-only admission, the VM_MAYEXEC > handling and the flag ordering above; the file reference now comes from > an earlier fix that takes it for every file-backed VMA. > > Assisted-by: LLM > Signed-off-by: Konstantin Khorenko > --- > include/linux/mm.h | 12 ++++++++++-- > mm/madvise.c | 30 +++++++++++++++++++++++++----- > mm/memory.c | 2 +- > mm/mmap.c | 53 ++++++++++++++++++++++++++++++++++++++--------------- > 4 files changed, 74 insertions(+), 23 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 91f305fd5c025..496cbdfc7141a 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1018,6 +1018,16 @@ static inline bool vma_is_anonymous(struct vm_area_struct *vma) > return !vma->vm_ops; > } > > +/* > + * Shared PFN mapping of a file, such as a device BAR mapped through VFIO. > + * Its vm_ops may be NULL, so it must be tested before vma_is_anonymous(). > + */ > +static inline bool vma_is_shared_pfnmap(struct vm_area_struct *vma) > +{ > + return vma->vm_file && > + (vma->vm_flags & (VM_SHARED | VM_PFNMAP)) == (VM_SHARED | VM_PFNMAP); > +} > + > /* > * Indicate if the VMA is a heap for the given task; for > * /proc/PID/maps that is the heap of the main task. > @@ -2481,10 +2491,8 @@ void free_pgd_range(struct mmu_gather *tlb, unsigned long addr, > unsigned long end, unsigned long floor, unsigned long ceiling); > int > copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma); > -#ifdef CONFIG_PADATA > int copy_page_range_mt(struct vm_area_struct *dst_vma, > struct vm_area_struct *src_vma); > -#endif > int generic_access_phys(struct vm_area_struct *vma, unsigned long addr, > void *buf, int len, int write); > > diff --git a/mm/madvise.c b/mm/madvise.c > index e6972bcfc9749..2b33d41b6ccf4 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > > #include > > @@ -1249,6 +1250,22 @@ static long madvise_guard_remove(struct vm_area_struct *vma, > &guard_remove_walk_ops, NULL); > } > > +/* Only VFIO device mappings are known to cope with a copy in another mm. */ > +static bool vma_doexec_pfnmap_ok(struct vm_area_struct *vma) > +{ > + bool (*is_vfio)(struct file *file); > + bool ret; > + > + if (vma->vm_ops && vma->vm_ops->close && !vma->vm_ops->open) > + return false; This breaks qemu-update with vGPU directly when attempting madvise(MADV_DOEXEC): MADV_DOEXEC failed on memory region 0000:bd:00.4 region 0 mmaps[2]: addr=0x7f5fc006c000 length=192512: Invalid argument The reason being: NVIDIA maps the BAR0 pieces with vm_ops which has no .open(): static const struct vm_operations_struct vgpu_sparse_ops = { .close = vgpu_mmio_close, }; My previous commit didn't have this check and it worked. Andrey > + is_vfio = symbol_get(vfio_file_is_valid); > + if (!is_vfio) > + return false; > + ret = is_vfio(vma->vm_file); > + symbol_put(vfio_file_is_valid); > + return ret; > +} > + > /* > * Apply an madvise behavior to a region of a vma. madvise_update_vma > * will handle splitting a vm area into separate areas, each area with its own > @@ -1309,12 +1326,15 @@ static int madvise_vma_behavior(struct vm_area_struct *vma, > break; > case MADV_DOEXEC: > /* > - * MADV_DOEXEC is only supported on private, non-executable, > - * non-stack, non-special anonymous memory and if the > - * VM_EXEC_KEEP flag is available. > + * MADV_DOEXEC is supported on private, non-executable, > + * non-stack, non-special anonymous memory, and on shared > + * PFN mappings of VFIO devices, if the VM_EXEC_KEEP flag > + * is available. > */ > - if (!VM_EXEC_KEEP || !vma_is_anonymous(vma) || > - vma->vm_flags & (VM_EXEC | VM_SHARED | VM_STACK | VM_SPECIAL)) { > + if (!VM_EXEC_KEEP || vma->vm_flags & (VM_EXEC | VM_STACK) || > + (vma_is_shared_pfnmap(vma) ? !vma_doexec_pfnmap_ok(vma) : > + !vma_is_anonymous(vma) || > + vma->vm_flags & (VM_SHARED | VM_SPECIAL))) { > error = -EINVAL; > goto out; > } > diff --git a/mm/memory.c b/mm/memory.c > index 2566f02fb7d5e..2f15bc06ccf90 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -2239,7 +2239,7 @@ void zap_vma_mt(struct vm_area_struct *vma) > struct mmu_notifier_range range; > > mmap_assert_write_locked(vma->vm_mm); > - if (vma_is_anonymous(vma)) { > + if (vma_is_anonymous(vma) && !vma_is_shared_pfnmap(vma)) { > lru_add_drain(); > mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma->vm_mm, > vma->vm_start, vma->vm_end); > diff --git a/mm/mmap.c b/mm/mmap.c > index 69dd1514d750e..959810d8047a8 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1752,31 +1752,41 @@ int insert_vm_struct(struct mm_struct *mm, struct vm_area_struct *vma) > > /* > * The VM_MAYEXEC that MADV_DOEXEC took from @vma, to give back when the mark > - * goes: what do_mmap() grants such a mapping. > + * goes: what do_mmap() grants such a mapping. A driver may have withheld it > + * from a PFN map, so leave that one without it. > */ > vm_flags_t vma_doexec_mayexec(struct vm_area_struct *vma) > { > - if (vma->vm_file && path_noexec(&vma->vm_file->f_path)) > + if (vma_is_shared_pfnmap(vma) || > + (vma->vm_file && path_noexec(&vma->vm_file->f_path))) > return 0; > return VM_MAYEXEC; > } > > /* > - * Duplicate an anonymous VMA into a new mm as part of preserving > - * it across exec. > + * Duplicate a VMA into a new mm as part of preserving it across exec. > + * > + * Anonymous VMAs get their pages shared with the new mm fork-style. > + * Shared PFN mappings (e.g. VFIO BARs) are duplicated the way fork > + * duplicates a shared file mapping: same file, same special PTEs, > + * nothing to copy-on-write. > */ > int vma_dup(struct vm_area_struct *old_vma, struct mm_struct *mm) > { > struct vm_area_struct *vma; > unsigned long npages; > + bool pfnmap = vma_is_shared_pfnmap(old_vma); > int ret = -ENOMEM; > > - if (WARN_ON(!vma_is_anonymous(old_vma))) > + if (WARN_ON(!pfnmap && !vma_is_anonymous(old_vma))) > return -EINVAL; > > if (find_vma_intersection(mm, old_vma->vm_start, old_vma->vm_end)) > return -EEXIST; > > + /* As in dup_mmap(), keep per-VMA lock users out of the source. */ > + vma_start_write(old_vma); > + > npages = vma_pages(old_vma); > vm_stat_account(mm, old_vma->vm_flags, npages); > > @@ -1784,6 +1794,10 @@ int vma_dup(struct vm_area_struct *old_vma, struct mm_struct *mm) > if (!vma) > goto fail_nomem; > > + /* track_pfn_copy() will later take care of copying internal state. */ > + if (pfnmap) > + untrack_pfn_clear(vma); > + > ret = vma_dup_policy(old_vma, vma); > if (ret) > goto fail_nomem_policy; > @@ -1797,17 +1811,24 @@ int vma_dup(struct vm_area_struct *old_vma, struct mm_struct *mm) > > /* > * Clear functionality that should not carry over to the new > - * process. Note that VM_EXEC_KEEP is cleared later to allow > - * code called by copy_page_range to infer that the copying is > - * for preserving over exec and not for process forking. > + * process. Note that VM_EXEC_KEEP of an anonymous copy is cleared > + * later to allow code called by copy_page_range to infer that the > + * copying is for preserving over exec and not for process forking. > */ > vm_flags_clear(vma, VM_LOCKED|VM_LOCKONFAULT|VM_UFFD_MISSING|VM_UFFD_WP|VM_UFFD_MINOR); > vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX; > + /* Once linked, unmap_mapping_range() may modify the flags concurrently. */ > + if (pfnmap) > + vm_flags_clear(vma, VM_EXEC_KEEP); > > + /* Also links a file VMA into the file's i_mmap, for unmap_mapping_range(). */ > ret = vma_link(mm, vma); > if (ret) > goto fail_nomem_vma_link; > > + if (pfnmap && vma->vm_ops && vma->vm_ops->open) > + vma->vm_ops->open(vma); > + > /* > * Now that the dup vma is inserted into the mm, clear VM_ACCOUNT > * from old_vma. Since vma_dup() is only called during exec to > @@ -1815,14 +1836,16 @@ int vma_dup(struct vm_area_struct *old_vma, struct mm_struct *mm) > * process, this effectively transfers the accounting from the old > * vma to the new one. > */ > - vm_flags_clear(old_vma, VM_ACCOUNT); > + if (old_vma->vm_flags & VM_ACCOUNT) > + vm_flags_clear(old_vma, VM_ACCOUNT); > > -#ifdef CONFIG_PADATA > - ret = copy_page_range_mt(vma, old_vma); > -#else > - ret = copy_page_range(vma, old_vma); > -#endif > - vm_flags_mod(vma, vma_doexec_mayexec(vma), VM_EXEC_KEEP); > + /* For PFN maps this copies the device PTEs and the PAT memtype */ > + if (pfnmap || !IS_ENABLED(CONFIG_PADATA)) > + ret = copy_page_range(vma, old_vma); > + else > + ret = copy_page_range_mt(vma, old_vma); > + if (!pfnmap) > + vm_flags_mod(vma, vma_doexec_mayexec(vma), VM_EXEC_KEEP); > > return ret; > > _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel