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 8FAB0CF34C1 for ; Thu, 3 Oct 2024 20:23:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD8C06B042C; Thu, 3 Oct 2024 16:23:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C884E6B042D; Thu, 3 Oct 2024 16:23:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B76C38D0005; Thu, 3 Oct 2024 16:23:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9A8316B042C for ; Thu, 3 Oct 2024 16:23:41 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4D29A40286 for ; Thu, 3 Oct 2024 20:23:41 +0000 (UTC) X-FDA: 82633416642.20.C24DEEB Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) by imf23.hostedemail.com (Postfix) with ESMTP id 8A89914000A for ; Thu, 3 Oct 2024 20:23:39 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uU3enpMV; spf=pass (imf23.hostedemail.com: domain of 3Sf3-ZgsKCH4cemgtng0vpiiqqing.eqonkpwz-oomxcem.qti@flex--ackerleytng.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3Sf3-ZgsKCH4cemgtng0vpiiqqing.eqonkpwz-oomxcem.qti@flex--ackerleytng.bounces.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=1727986847; 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: in-reply-to:in-reply-to:references:dkim-signature; bh=bsrxlfd04OhEv+n0CPbWpU82YP7zkM1b/vn5t74+eZQ=; b=7VhgeyqoDNzVEKfjEo1WgMo3mjw2Ixd4qOzPbarspD3shE5Nyx744zIY7uT8UpXiPa5LeO WS4meK+GoGd00s7sej3iJrZ1OLbkadnG0j3hmqrPR5m1mrpZEDui1Uc0kw1FrqS7EM5Uev mA7IOsKY3JEwfwL+GWnY8TK3lHOMmj8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uU3enpMV; spf=pass (imf23.hostedemail.com: domain of 3Sf3-ZgsKCH4cemgtng0vpiiqqing.eqonkpwz-oomxcem.qti@flex--ackerleytng.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3Sf3-ZgsKCH4cemgtng0vpiiqqing.eqonkpwz-oomxcem.qti@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727986847; a=rsa-sha256; cv=none; b=ZL8gmHoOobLeb1BvBZIN6m28yuT0p88WKPw+Ht3gOXOHsxE0i3S/zZjZ4zE+s4TTsmMptq MHqmmcyTdsjRvAZyBEFeORclm5UEwqc+lmS1rbAc0fH2IOIzldnG3vXCfTCzi04nXV0cL+ N75koXn2gTYJbSU4kSxEY0HiG0Ni0PA= Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-6c8f99fef10so1583137a12.3 for ; Thu, 03 Oct 2024 13:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727987018; x=1728591818; darn=kvack.org; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=bsrxlfd04OhEv+n0CPbWpU82YP7zkM1b/vn5t74+eZQ=; b=uU3enpMVPtX6VZw/RNvedOd2peLr9/MPOjWGdmx4lhzZWb1XjImCZWtLowq4Zz1DV3 MUlJe65w/KrG1BA5dpv+iHQPjE6q0APznb8xf53r60zZi1oLCfj5jTGvQAoHHdMzRJUn lCn3ZNgeEjMrNbAtqwXjB7FylCbU76hoxp7/bE5bboXlan746wIJZYduw770zFG7rBtn qrFPnz0ZqFNNdu1DCJTrV4oB4mI0qKvlbcdpLIONQOYf0qI6MjU1YJIIX/+8qR4/gAZA iLL9fbPHjvJcWBC2BBlojqNCT7HizN6DYuLXUqsNLOzYJ6/lFdVIOvW2FXCNm7PoycOv 4Rzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727987018; x=1728591818; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bsrxlfd04OhEv+n0CPbWpU82YP7zkM1b/vn5t74+eZQ=; b=RnJhaH4JE8OJteXPDWtfyn2grkhwKnxSLQGx9YFsFIZI51KkLdsbe6w54beAmT8EnW JRc9gCIaVl63pPLC37xpc9pz9X+R6yYA6VkR7PVyo7byzAZBQpkf3diiGZ04T6vnWAVV 3m5VArEZATh+sIaOIfDQGfQdrl7BQdWMeK4veGMDo88RzrT9QueJpOXJ91F3RqCbMKIp JKIGfUuixjxLGQ1yB/o/T7TmAq/L9arRvWWRFYvlXBCymvQIx2aV6tj7vG02i4GN76Xg OX2h3/a7XFXzMBvcUPAjc1zy29gpGVQsIMmL5T+CbtVwSZ9OEHLN0Fw+L5N0CI0LIXkL 7IGQ== X-Forwarded-Encrypted: i=1; AJvYcCWBEHTEejnSBcvAeM0w2FDzIBSyw71pQQOMMF97GFr1iivGJdFM+A9aVuAeWG/tpbLkhcgv7QMAwg==@kvack.org X-Gm-Message-State: AOJu0YxRGPIPVQXsKyHiT9KDFqI5L/7gjd6d98amDKLJXRqQ4d61uYo5 zmwAMMGO413xyhSc41hmaxxdiM0W7VQDcxL9YTInBI2Gkd+7eskGVi8O9LH9oTKWpckwqD2Lw3z Xy0QLPM0TxHwdiyYxo69GOg== X-Google-Smtp-Source: AGHT+IFpD6BWHM5h+33v0jB6Q6n9bSyUbGf9Hz29V0yy4Czzzteo1cbIqPdjyXE3Ss97ow9Hj9/CtpXBjfv/MY3knw== X-Received: from ackerleytng-ctop.c.googlers.com ([fda3:e722:ac3:cc00:146:b875:ac13:a9fc]) (user=ackerleytng job=sendgmr) by 2002:a17:903:187:b0:20b:bd8d:427a with SMTP id d9443c01a7336-20bfe17d820mr65455ad.5.1727987017910; Thu, 03 Oct 2024 13:23:37 -0700 (PDT) Date: Thu, 03 Oct 2024 20:23:36 +0000 In-Reply-To: <20240913151802822-0700.eberman@hu-eberman-lv.qualcomm.com> (message from Elliot Berman on Fri, 13 Sep 2024 15:26:30 -0700) Mime-Version: 1.0 Message-ID: Subject: Re: [RFC PATCH 15/39] KVM: guest_memfd: hugetlb: allocate and truncate from hugetlb From: Ackerley Tng To: Elliot Berman Cc: tabba@google.com, roypat@amazon.co.uk, jgg@nvidia.com, peterx@redhat.com, david@redhat.com, rientjes@google.com, fvdl@google.com, jthoughton@google.com, seanjc@google.com, pbonzini@redhat.com, zhiquan1.li@intel.com, fan.du@intel.com, jun.miao@intel.com, isaku.yamahata@intel.com, muchun.song@linux.dev, mike.kravetz@oracle.com, erdemaktas@google.com, vannapurve@google.com, qperret@google.com, jhubbard@nvidia.com, willy@infradead.org, shuah@kernel.org, brauner@kernel.org, bfoster@redhat.com, kent.overstreet@linux.dev, pvorel@suse.cz, rppt@kernel.org, richard.weiyang@gmail.com, anup@brainfault.org, haibo1.xu@intel.com, ajones@ventanamicro.com, vkuznets@redhat.com, maciej.wieczor-retman@intel.com, pgonda@google.com, oliver.upton@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-fsdevel@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8A89914000A X-Stat-Signature: mz9acj88nfw9gr5ybfk95se1ppw4w1is X-Rspam-User: X-HE-Tag: 1727987019-102314 X-HE-Meta: U2FsdGVkX1/LAFNlPkHt5Oy0QWRuQrEXZV5y09oRfu9TR8SpEeoAGaT/lazKJrZVKajioOw4Oe5/6t8EwGzoejr4u++/mVn19ZSyLYo5oDnTBVtle+64407S3X88iHEPKBxev3UGvM0nOZ5pqtHcsFelh/QW59BCIpvaJ9KIg/fh1QrdTlH9UnRh1p3zOOFEl5PvV8U4nw9AfXwva54I0rkw5LGPlEyVanpymh+FcnBvyfOtYgmT7EaaBRW7E/LW/fjVtThSCB5WkPZvsoyzeaDy+IkLyZ4ZAcd3Me7nJFEKs7b4N3DNP5G86ldiMFkSGym0RKntLrEww2AS0qODnMzsjZFfCAdErsqINpYbrlqUPeLcexIMhOusXCKFtQIS5PwmM31RS45p5MrFK4fxrtfYI4hAdAs3CjJrkasANRGvWZ2TiTql83kqE2cpctNgGCkkmNW/XlsM2+R9oIxSS3D7ZzBg3LcP2+77dNtXgGabwsMRN7f3O7ImnWW+jEaSDYNdgZ2N1VywOwEcUSAic678979/M9pA3jN0cE5NPFdDtP3f6KrDVPcrdlXCWhY06AM5mlAvxJIj3WMLvEQmyNTMeK78/ySN0SQTu6opdSUaWxcM2dSXyjf22g45a7K4mH3S9zmxGMYJBPZdFPTaYzAUwBA41no5p0hgHS7XQoN0ORXyn2azKw6Skbh8n+AEwgklC5Juw+/Wh8P+B4ycIxXNdcW0nYPslLhciGM9LKO4W1GC9Q9T1jJ6WpX0pBcY4LszSMZTfr7V8QSoyM8eIHCgQF2rPmBH0Uo94kS3x2TOwPeNtRME9Jp4VsSiRSSDyg/BEkdlE97eS8dcsgi754PDu9ZSwo3Wxjv0prIQWISXeKMs8QyirPIrKfas3N3D/XL6hP5u+W7w/R433S7rVLV4KCzoIFhLekPbNC7jqZY1QtYZhlB2eWErgk0e8WSePwIq1bstgIXGPMcMn9I KW8hm1Ak C+A1KNhLRO5G5npQ+j/ceTOgZGJyTfGGfTjOiwXURlWFy1UBa+jSJJHuHvyMJOJEdUupTFKLJKk7+dFbpzW4xu3TMCZMCkj3a7E9WJ+VwSour0spAxF7POOzKB2j2NUE6F0DjmHctV3yk8nvtW8rjqcAhonEOJagmZ2dxcV4XnSoOI1SzHJCBpscSbefieRlI2Ipmd9blFTWi0V/+6xd+q1DA4Rwk/YmLZ5ijm7k0owQN2qiyFr0sbHZQFJJ8kSJIbM+heSTKQeGdRCSqH4qtXrTgICNQL3ehQbc73igOocV4IqsStK80DdhKKOFKfOnLUZJJdmp1h8393mZuT+Ekge93SB00uO8XUD8qcn7ncT0Zvqc+blrDnyuBNkjARy7JKM4j4941SwFKPbD6aZ4iW0cZdHlIoawp3eAKQUEzaygx5u48qst6tdz42UK/LYU+w5FxhV2iZC0UzSk+tCSYIL07QktYg5ct1Kw2pe8j5JGUksQH4OFpyaxS6tkcjzkEOK6ng5zzHAOVCkKdsVJ91utv44hUs4ZE2kvtOUFOTIalP+9xwJhfuPOZ2Q20Dohu6RSX8vsGAHfB3oUVfUr6UkCqmp2RDHs8zcIB/xmv5yNzoqrrtnTDzwqtrNLzYoQpRzdiHVBr+6/RxhpBWhp2jMpCsPQAlBFXCH8AOrQVOy1ozEgAJQML1fZKoSAN12OxFHYMkJ4/eT7BARTkhWoHBcwkl5PEnm1Y0lxPaOdN1fCDulI6mTM+VIGGUw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Elliot Berman writes: > On Tue, Sep 10, 2024 at 11:43:46PM +0000, Ackerley Tng wrote: >> If HugeTLB is requested at guest_memfd creation time, HugeTLB pages >> will be used to back guest_memfd. >> >> Signed-off-by: Ackerley Tng >> >> >> >> +/** >> + * Use the uptodate flag to indicate that the folio is prepared for KVM's usage. >> + */ >> static inline void kvm_gmem_mark_prepared(struct folio *folio) >> { >> folio_mark_uptodate(folio); >> @@ -72,13 +84,18 @@ static inline void kvm_gmem_mark_prepared(struct folio *folio) >> static int kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slot, >> gfn_t gfn, struct folio *folio) >> { >> - unsigned long nr_pages, i; >> pgoff_t index; >> int r; >> >> - nr_pages = folio_nr_pages(folio); >> - for (i = 0; i < nr_pages; i++) >> - clear_highpage(folio_page(folio, i)); >> + if (folio_test_hugetlb(folio)) { >> + folio_zero_user(folio, folio->index << PAGE_SHIFT); > > Is (folio->index << PAGE_SHIFT) the right address hint to provide? > I don't think we can say the folio will be mapped at this address since > this value is an offset into the file. In most cases, I believe it > won't be mapped anywhere since we just allocated it. vaddr in folio_zero_user(folio, vaddr) is eventually passed to clear_user_page(). clear_user_page() uses vaddr to clean up dcaches on some architectures, according to Documentation/core-api/cachetlb.rst. In this patch series, folio_zero_user() is used in 2 places: + kvm_gmem_prepare_folio() + kvm_gmem_fault() folio->index is valid by the time folio_zero_user() is called in kvm_gmem_prepare_folio(), because when kvm_gmem_prepare_folio() is called, the folio is already in the filemap, and folio->index is set when the folios is added to the filemap. In kvm_gmem_fault(), kvm_gmem_get_folio() also returns a folio in the filemap and so folio->index is valid by the tiem folio_zero_user() is called. Hence in both cases where folio_zero_user() is called, folio->index << PAGE_SHIFT returns the offset in the file. In hugetlb's fallocate, the offset within the file is passed in the call to folio_zero_user(), which is why the offset within the file was used here. In the next revision I will refactor this to something like kvm_gmem_prepare_folio_shared() and kvm_gmem_prepare_folio_private(). In kvm_gmem_prepare_folio_private(), folio->index << PAGE_SHIFT can still be passed as addr_hint to align with HugeTLB. When being prepared as a private folio, the folio will be mapped by KVM: addr_hint won't matter since this folio isn't going to be mapped into userspace. If the folio was previously used as a shared page, unmapping would have flushed the dcache. In kvm_gmem_prepare_folio_shared(), the folio will subsequently be mapped and vmf->real_address should be passed as addr_hint. Thanks for this question!