Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 11 May 2023 13:22:43 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Axel Rasmussen <axelrasmussen@google.com>
Cc:     Alexander Viro <viro@zeniv.linux.org.uk>,
        Andrew Morton <akpm@linux-foundation.org>,
        Christian Brauner <brauner@kernel.org>,
        David Hildenbrand <david@redhat.com>,
        Hongchen Zhang <zhanghongchen@loongson.cn>,
        Huang Ying <ying.huang@intel.com>,
        James Houghton <jthoughton@google.com>,
        "Liam R. Howlett" <Liam.Howlett@oracle.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        "Mike Rapoport (IBM)" <rppt@kernel.org>,
        Nadav Amit <namit@vmware.com>,
        Naoya Horiguchi <naoya.horiguchi@nec.com>,
        Peter Xu <peterx@redhat.com>, Shuah Khan <shuah@kernel.org>,
        ZhangPeng <zhangpeng362@huawei.com>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 1/3] mm: userfaultfd: add new UFFDIO_SIGBUS ioctl
Message-ID: <20230511202243.GA5466@monkey>
References: <20230511182426.1898675-1-axelrasmussen@google.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230511182426.1898675-1-axelrasmussen@google.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wANhYg5M50O6+W8w9ro63Y8i2v5TpeYoK8wV6NxYzSwNjQOnEkNBL8UerdE7?=
 =?us-ascii?Q?lX0QTFy06XtK/b/OQBNgnsesiwmeezHycKipiQMHP3bwLpyvOiyxFVrxEBYJ?=
 =?us-ascii?Q?5f9Ce6vBaloFb/2DLF2TuHdIHWB30gRhmcyahQzSFpWi+++q4inOo4mon9K7?=
 =?us-ascii?Q?vVG9fIldp7AtQcEeA+s8roJazMrIM0jwcxxnma5I82brW3kGOCVu32sMXdq+?=
 =?us-ascii?Q?mb8ZGaCoVhk1YEIgoWTqRQ0OjkN4tjP2cLeueclDO8p7+WLGYSGqCmCpou7d?=
 =?us-ascii?Q?oZwsVGHPDU31leJtbJZb06a9b/n0Z3jIIHkk+6bV6E3QvGP3tieRdOZxfpEo?=
 =?us-ascii?Q?yF/VgVobC5p1czwLiP+iDwQoSht6KZ32tpjiUbMXAOdE+U/+QyeBjjf6ZTRK?=
 =?us-ascii?Q?C0aQLmeFqBNlJbf6TZIPaN3g9GsBinLC18szpVRMi5CAP9S3FfJrzawQVt4t?=
 =?us-ascii?Q?7+9lSCaA7msTmZ7XwLJVZtZuwQXaxEKFLKTJAFcscF2pvZIQGCzltlXHag8V?=
 =?us-ascii?Q?hGHB+s/8gixJbvd9dCHQXn5FVmme1eTxrbYvTjQPhbw2PVi8uXhV7wzARfuq?=
 =?us-ascii?Q?5ojWmojnva2DMcxXybTk1EyDxFslLnob5onUWNxwCix0iAjZ+fLNthlBq/lw?=
 =?us-ascii?Q?KKe5ytrViSdLD6fJ9wLAXBGkKgCYjcaBdqwC2TYRYRMtHxKwWRo3J6FbJc+x?=
 =?us-ascii?Q?EY0gumRtCECkKlHuucfEDcTM7trqR5o8EV0P8c8Pkh6BIqQzyEEUhwFS8tT/?=
 =?us-ascii?Q?RK7bYpemfPBNmqDS9J2BPz1t5Qa0TTqXXrdNECbdcJ7fFqgz8Qu1kv80UPCW?=
 =?us-ascii?Q?Hpa7DHSsmLJcKpjJmpuLiBzEJrFC667DDGjcd873wVhRA/Pe3NXBA5LCuDRY?=
 =?us-ascii?Q?vSy1VwjW9f53zquRKQSZW2Op+SLwCTflBQRMKedjiD9DttZehbZ5hIcDYVYT?=
 =?us-ascii?Q?QK/4qpi3Ou46tRQSK7eOXthcnFcEVRhWMMC4DYYg1FdtFtowS7cJRs5vcAmC?=
 =?us-ascii?Q?Zf9/IXIEGyEII2+92nsEtgs6qP3fZeQzni+zVgan4nR5f4ls3aRjH21amHgy?=
 =?us-ascii?Q?uXjB9QhnfRRTR9EqZnrxe8PhjPFYT4eJeJE3QnW5Bz16gy3xYabnlMhT+tBh?=
 =?us-ascii?Q?IfdHeVsf18QRc96ty3Ae4jOV077Z2Yfu4HbL0iVLuBerqKXOrQn3fTbO3SIh?=
 =?us-ascii?Q?Zo9ejdvaOHVhy4r861ARsibm7E9ZWKh+zK6cj9/deY8+J9p143CklGxuLXT8?=
 =?us-ascii?Q?ZQNOvTueMaZfxBFLXWGypOth4+c6W4bjayi/m9I2DRZZ9f0/Zw8r4NlLcFfz?=
 =?us-ascii?Q?hcpRx7/QeWuaXEfClP5xKBok1EPQOSgNFYIpA1VqGw9lrCByS6+qtglhW8R2?=
 =?us-ascii?Q?OnIdVq5q8ouZnMrz5kHYx5ju0wEayNzc3Etf/LSr0t7DrzU5XStng3CcV6aK?=
 =?us-ascii?Q?39D6Eex5X9X4wRyoI4GV4Mh3DpDedKoqjNesevY/Xo0gPjYODdyKCir+08Zh?=
 =?us-ascii?Q?A5oqa91a6PwzE0Tp0eyvIYvZmNYdrn7iADMl/WuxoT+8zqiFdwOY2MhcHTSf?=
 =?us-ascii?Q?lrCadHW/LHP536lTDg1Ou384sRl45YrUj6fO7zn8?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?6vK4Ucuf1ikvnIw2A57soMEU5TYkSoNE8u/8KsfUTnctMQnwM/jizWSo1Fx0?=
 =?us-ascii?Q?jPEouzJeMXeftLVeTKvXs022/Aa2oieetvlKWLMT9RKPPen2LS/Fy/d65RoY?=
 =?us-ascii?Q?FnRNt22zc3SrZcJpU1mD+ct5xyGwI6YIBJMH5xkEHSIwxeyVcfMnyxkdqhWH?=
 =?us-ascii?Q?fjV+wudDWjPAOws21ZjsD73AqNS+rBQaXAKpt4Pnoz1MFWzsISPc421jIQgJ?=
 =?us-ascii?Q?AVgA2XaekrPj2f4ESWF1mTJOiKdny11CErOdVu7W8H7QBWNpDC4kMGnG5Qiq?=
 =?us-ascii?Q?f0txR60l8H2qxWGlWx/G5vVBX2Je6DBemWffZB47vSqcWQGXWXkASo0+UVPu?=
 =?us-ascii?Q?4zVND0MU3DfMJ0MOkgg0rBH483/Zaua80QXQ3dOEAbdleQMkcRZ15xLTjkL4?=
 =?us-ascii?Q?xO2fxeBGxWJyeceGg8uVe4e7L9HZQGo3Mnuz6h/D9J2s8+odKoTuO181s4oW?=
 =?us-ascii?Q?rsCKKVU5lITnH+mJxAFrtgW1cElKVLLDAjLEuhywMW9WzEUcDYEv85nLm0Kh?=
 =?us-ascii?Q?ANTpU3U2hEhEX0zYKHCs8issv9X5JdMITurxgkWVIxhToovQDVNL4T+knhif?=
 =?us-ascii?Q?c/HVQxVqBKLsGMt+xGTyzJl1QtFX3hvMO1dfNJapVnlfXztL8esOkg/mXww9?=
 =?us-ascii?Q?dq1No6KgWzRSJIDVe2cIYA+7yVwlDaT1MT/SqpPgqtesndFwmbB4NfQFvIiI?=
 =?us-ascii?Q?XFK8yulGrD9/nfCau8Zd3ZUA612z/qUbnrt6NB+qNqJ0tljQ1vIdy687WnqO?=
 =?us-ascii?Q?WZRFuPbfUt0KNyvWV7l5/KoD2o9M6ncdWjXfb+0epb9iWXYftkQ6LHbUW7R1?=
 =?us-ascii?Q?RSKeVfxUs0VkuTPEIFEbAtNwQgL0feU8+7Da7omcBMX0eQbQQkci5msVtkNo?=
 =?us-ascii?Q?BSJ9RH1aolH/Q4UEXp6OvlwZhgtD61FILYy8u78zzPdIARXmLbgv1noGBFth?=
 =?us-ascii?Q?UJxpjuIgkaB8wSA7qOET2D7Rz63TnKTYlEHJyqMG6DPmkeZasVNd5VjjovCh?=
 =?us-ascii?Q?YRDPDv0R8/kYuXaQ4OwEskQx7tOMuK9WunYV2W63rKq1Bz+buBxsRyMR7mxu?=
 =?us-ascii?Q?tjp5dEHQPbZaneptvUx5tr234AVyJ5QRHQdigwNu6eEMOINRqhFdaEEZMaDE?=
 =?us-ascii?Q?hnCcZgSOpx95?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c98e1d6f-f5f9-4f37-6630-08db525d7c10
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2023 20:22:47.1955
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4AyffKTxDGEmW/EVg4hodBkHPJOzM4xPN/OPNwdQWsasvDDpKJFEelDzZlmtkvsJM9O0Lr8bTldihjNvfNVQzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR10MB7760
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-05-11_17,2023-05-05_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0
 adultscore=0 spamscore=0 suspectscore=0 malwarescore=0 bulkscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2304280000 definitions=main-2305110174
X-Proofpoint-GUID: W5GM3WaUrLTtsZp9C3bmFtkxgG9S5cfX
X-Proofpoint-ORIG-GUID: W5GM3WaUrLTtsZp9C3bmFtkxgG9S5cfX
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 05/11/23 11:24, Axel Rasmussen wrote:
> The basic idea here is to "simulate" memory poisoning for VMs. A VM
> running on some host might encounter a memory error, after which some
> page(s) are poisoned (i.e., future accesses SIGBUS). They expect that
> once poisoned, pages can never become "un-poisoned". So, when we live
> migrate the VM, we need to preserve the poisoned status of these pages.
> 
> When live migrating, we try to get the guest running on its new host as
> quickly as possible. So, we start it running before all memory has been
> copied, and before we're certain which pages should be poisoned or not.
> 
> So the basic way to use this new feature is:
> 
> - On the new host, the guest's memory is registered with userfaultfd, in
>   either MISSING or MINOR mode (doesn't really matter for this purpose).
> - On any first access, we get a userfaultfd event. At this point we can
>   communicate with the old host to find out if the page was poisoned.

Just curious, what is this communication channel with the old host?
-- 
Mike Kravetz

> - If so, we can respond with a UFFDIO_SIGBUS - this places a swap marker
>   so any future accesses will SIGBUS. Because the pte is now "present",
>   future accesses won't generate more userfaultfd events, they'll just
>   SIGBUS directly.
> 
> UFFDIO_SIGBUS does not handle unmapping previously-present PTEs. This
> isn't needed, because during live migration we want to intercept
> all accesses with userfaultfd (not just writes, so WP mode isn't useful
> for this). So whether minor or missing mode is being used (or both), the
> PTE won't be present in any case, so handling that case isn't needed.
>