From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60575C02198 for ; Wed, 5 Feb 2025 17:39:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3B14280004; Wed, 5 Feb 2025 12:39:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AEABF280003; Wed, 5 Feb 2025 12:39:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98B16280004; Wed, 5 Feb 2025 12:39:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7BE0C280003 for ; Wed, 5 Feb 2025 12:39:25 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0D7291C7F7A for ; Wed, 5 Feb 2025 17:39:25 +0000 (UTC) X-FDA: 83086602690.06.2FB0681 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf02.hostedemail.com (Postfix) with ESMTP id 06F4580012 for ; Wed, 5 Feb 2025 17:39:22 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UbBPf8MC; spf=pass (imf02.hostedemail.com: domain of vannapurve@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=vannapurve@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738777163; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DEZm5CUmXLka1TAInFV81IX5nQDZQzMEScT7OiIQ9Q0=; b=01KK2hXnFlVjzkDQyVR707K+j5voqnNxRJ0Gr0grC2JcubUVjOP+9yArgwvHh+i+LeBQsM juDHpIWRr27YbUWOPoWpW80TDqZdp2ghdf/x7u1i8f0h6RtZBFunhvr90vSi4iyvUkaQrc j9chc1sEwl/KrzG6k+W/BhGAr8ooNW8= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UbBPf8MC; spf=pass (imf02.hostedemail.com: domain of vannapurve@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=vannapurve@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738777163; a=rsa-sha256; cv=none; b=DFacZpo7+NqGdLh1e1gZUh2NWOhAmExHrCU7AJSlW+boLchLoqMrxeQG+carTIT2DEPk1W D7DKYrlmfUldOl2Petd5PKClExwMvE570+hJl/QP9b2Tl2XFk+JkaBz3ZvJ+ufCYBvKv2O USnzYHpfj3zk0gAQdQCtTocE5Db4w2M= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-5440e81be1bso35e87.1 for ; Wed, 05 Feb 2025 09:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738777161; x=1739381961; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DEZm5CUmXLka1TAInFV81IX5nQDZQzMEScT7OiIQ9Q0=; b=UbBPf8MCDm9r/2cZlLa96evri0trVPk4r9TXQERkBoTTWo2Fft1DSYUDibJdNqwrg3 uI0i0pzyuyVetDNJ4alUR4pHC3PE8erpgR5V7+PqbNsmJyrHo8WJWNdAfwHZEF1KOw1l 0d/QYFFIOmL1jPxrv63DGGM8jTx2TgHWxvU6oCOMQl+7wRdGpFlLC9ewf/wqxnL3XXYR d+TjUL4OYCxMIDpVUoRXaPcQG0/yyAcc5xVG+LpGyD1tu7nk6fQHgNxQX0MTfhM+bOaJ jSSKk5pTrOZwqKTl/aZufxnk6mEWLfzktyERK4ZBeTCTBaLmidYD2ordWw9lCJZ3nidN yV4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738777161; x=1739381961; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DEZm5CUmXLka1TAInFV81IX5nQDZQzMEScT7OiIQ9Q0=; b=SzdLYaqeU6vMYy0FG9Bs8P0thK/xPC8CPb1adC/hAOfJqo3c3/fMTfj6KWAtesRUCC 4Dy3FMlagHo46lK1tfcL2R17E33yRuSTvtfsVOQNYosI4jDbiHTPAjXlnQx20jHmTpvH PmWC2ySMRY6DFJ+K+g8mXLyegpT50dT9jQVY7rwOVaWCV82HM8q06jyXGL89Zx5RBTQB 6IC/MZciDJ5HbaFEshQ6jVbzepJIAIQGWarUM6e05A+iITEIvkb5LIZzTi5ixF1Blg9z ssXvCZCH0veMid2/gpcCAk+Drju88dKpskcK2ozwaTETt5U+kmxs3O7s4vZSnsn3u0xo n1YQ== X-Forwarded-Encrypted: i=1; AJvYcCUoch7QEX5DPISSqR19c2p/nXjLlYkd65iSfW315j/TtA+4aZLkkiLFQSvWHfDNcF81B2pqWX4GxQ==@kvack.org X-Gm-Message-State: AOJu0Yy4k5tee2ntnlHy6tKXjc33PAgkMNbkjj9cypFlwNvNf9TpgixY tWlPwggdy6YkkYtWlch8yp/1vk9HCFDQzB7DNY/9WjywXoI9s50TW9ZedhKL0kkr0KHLIbvgvqd eGcW/aLm6KPgFSCP+E/xUcX7mCC82Ddt9gVzQ X-Gm-Gg: ASbGncsAS1G0kcUzcj44CahbWXLAB7HAbEf5ddBHpd3Zke/1t91EiIHeMpVV0JUb8fH YeXt4b9vCzXHAJGAulRqvBFSrZAhEKdd4uiv5r/KQpf+lTaaSViODlYqKlBVtXs8lapvNj/vNG+ UWlmuL9oIpAQwhC9Qbyvm9EFbhXww+vw== X-Google-Smtp-Source: AGHT+IFkjWQJCxN4xPQHUS0Vsp6dW2ckurfVhTOGUtFDFseGDt7Z4hk2Am1DCR5yVIgGrmc0D3h4BOlH617tYtopub8= X-Received: by 2002:a05:6512:2398:b0:542:6b39:1d57 with SMTP id 2adb3069b0e04-54400bd9244mr589006e87.3.1738777160952; Wed, 05 Feb 2025 09:39:20 -0800 (PST) MIME-Version: 1.0 References: <20250117163001.2326672-1-tabba@google.com> <20250117163001.2326672-7-tabba@google.com> In-Reply-To: From: Vishal Annapurve Date: Wed, 5 Feb 2025 09:39:09 -0800 X-Gm-Features: AWEUYZm5Gj2iCzvuEETaqpk3nGpaMUbNOOKI88lb2YmSVbbpegGLse48NXXxP8o Message-ID: Subject: Re: [RFC PATCH v5 06/15] KVM: guest_memfd: Handle final folio_put() of guestmem pages To: Fuad Tabba Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, seanjc@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, yu.c.zhang@linux.intel.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, ackerleytng@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 06F4580012 X-Stat-Signature: eux6e5sp6158txn8nj1h4p4htzaop7nx X-Rspam-User: X-HE-Tag: 1738777162-704813 X-HE-Meta: U2FsdGVkX19LN4IKXeKGtsyfS284ZBlWb5tzKK2Vnn1tbxNQOjdkREQQ4fHJxTD2SkJy/Y60x4b1C6/mrmtGyAtfcfllvpSdD6CaD/KP2JfniZe2zCGbWxJmkvXesIMKZJZgHKS4HS/G40yebJC2xPhp02idhHBqmzl/fXwJaOm7rN42w5VDQn0vU8aGnZzlKcgS0Ze4AXXWrb2fIy1KtkBCKiAeUZ5AC8oY7kJsphk24K0jOVezjL61P3PdYGGQQSOAAHchut31BlcLz6UA6AWlVCuUuWXIBBgOaMtMmodKk4lO3qR1eYhfPg2K1aH2+9wkFEfObyZf5HtfAi47z7DjamoepT4vIktUGJRSrd3+nhCj+JGJ1/mlWdGz0zaYqcV+Y6JAzFYpCUaj2Q8VZMshyfcHc6/jKlYdOaqHF3z3SCJfrzDMBqRQjhlqH9ZkByCf7wr1B2EdRvESWgaSdzWz6z0rxOLlYO84wSd6BWwR/t5xgUzhBEka/SfnAjE4eKmx3RKb1Ltv9/tkMku05hygkn7YCG64HmMg7KgUV6Eek9nGoQ4jSXa41m8CFvEEWZyIWnat1DHs28Lrdlzi973mu7tzzE9kRo31lxRoazfa9frT6Yd/QBLgoAJmGvIthh/j+m6d7jShyI4SYeKxdtx1nacaSrmu5A8oCy7uBiewE9oUTXH8mfqFc71bKrL9o7rjcBwWg29HvRK6lqcZjnusAnC4Rk8WQOSvHHXXv4ll+fq7YIsxbX7n8sbraf6oQkK0/0rafMPrr4ptytGAnhqqVFrAOCZQ1GmhXgy76Q4ve+6L0G2IVt0jHGOZQaIynr8Pf6d+NccY+bNR84ue4a5gVfXcG+xVowrBs+lCTHFqzAdDO4brytQKGUsOJ59WHoUwIs3Q5ikt9wXCtfjJR9W6J8qdvHRPMH9jIzWa5GmEKoKwuVeGaIBV10riBAJUahCXQMW+zf+xI/unof0 Mu3oEdFL syfBqimENIdYliaDV+dfJMObig4B5/FTaJCp+b70Thvca7n14nfpz6I9C/fRmhq0PVe7IuAXZsKgNQ3fx1ElLjkLG00G9ecNVvPDsFCc9hlh6Ti0WQfP8Uh6UXkPH5qHa7caAgqKB3OtxxTEil2SlREya+4w4C7wVlCAJJPYLhFXFymuQfB37N+VVKK+22FjFfhiNu0HeZXf71CV/jlf95DiFHiIb1dqP3xDTwdlQfUZ2cnCDhnYH1waB6VwnNzCT4mQmT/zGCSr8x1SKExP96BSbmDGLm3c6ekouNnzXquXUpNNQY+mUcnGSo8T9dl8rpW/dnxsTkCIje1IfYg7XcoM/7EJNcQRZpE+rZ12fHCkLuYwm3oYs59YuAabfDyHaGCTSNqBMYmUDtFE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.021050, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 5, 2025 at 2:07=E2=80=AFAM Fuad Tabba wrote: > > Hi Vishal, > > On Wed, 5 Feb 2025 at 00:42, Vishal Annapurve wro= te: > > > > On Fri, Jan 17, 2025 at 8:30=E2=80=AFAM Fuad Tabba w= rote: > > > > > > Before transitioning a guest_memfd folio to unshared, thereby > > > disallowing access by the host and allowing the hypervisor to > > > transition its view of the guest page as private, we need to be > > > sure that the host doesn't have any references to the folio. > > > > > > This patch introduces a new type for guest_memfd folios, and uses > > > that to register a callback that informs the guest_memfd > > > subsystem when the last reference is dropped, therefore knowing > > > that the host doesn't have any remaining references. > > > > > > Signed-off-by: Fuad Tabba > > > --- > > > The function kvm_slot_gmem_register_callback() isn't used in this > > > series. It will be used later in code that performs unsharing of > > > memory. I have tested it with pKVM, based on downstream code [*]. > > > It's included in this RFC since it demonstrates the plan to > > > handle unsharing of private folios. > > > > > > [*] https://android-kvm.googlesource.com/linux/+/refs/heads/tabba/gue= stmem-6.13-v5-pkvm > > > > Should the invocation of kvm_slot_gmem_register_callback() happen in > > the same critical block as setting the guest memfd range mappability > > to NONE, otherwise conversion/truncation could race with registration > > of callback? > > I don't think it needs to, at least not as far potencial races are > concerned. First because kvm_slot_gmem_register_callback() grabs the > mapping's invalidate_lock as well as the folio lock, and > gmem_clear_mappable() grabs the mapping lock and the folio lock if a > folio has been allocated before. I was hinting towards such a scenario: Core1 C= ore2 Shared to private conversion .... -> Results in mappability attributes being set to NONE ... Trigger private to shared conversion/truncation for ... overlapping ranges ... kvm_slot_gmem_register_callback() on the guest_memfd ranges converted above (This will end up registering callback for guest_memfd ranges which possibly don't carry *_MAPPABILITY_NONE) > > Second, __gmem_register_callback() checks before returning whether all > references have been dropped, and adjusts the mappability/shareability > if needed. > > Cheers, > /fuad