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 B4AB5CEFC42 for ; Tue, 8 Oct 2024 19:30:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C06A6B009A; Tue, 8 Oct 2024 15:30:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 449D76B009B; Tue, 8 Oct 2024 15:30:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EA836B009C; Tue, 8 Oct 2024 15:30:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0941F6B009A for ; Tue, 8 Oct 2024 15:30:18 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3A9B11C63A8 for ; Tue, 8 Oct 2024 19:30:16 +0000 (UTC) X-FDA: 82651426074.03.A2F5F6F Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf06.hostedemail.com (Postfix) with ESMTP id E669618000C for ; Tue, 8 Oct 2024 19:30:15 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="PGwVy/Dl"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of 3RogFZwYKCKsdPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3RogFZwYKCKsdPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728415716; a=rsa-sha256; cv=none; b=Tf+/5tMyKT0wlVU95lIN1iKAMm6QWpMhK4dFgnr/bGaVK3J1o5atXQ0GpMOxkmaaConqpI f+ptTSF3edpUnu747cgTBamA/n9vatoWTZ+WvyUTGz9kJHFoBnsLLYnyqjSTdirFwU7L02 ZLqKmPfYLIy8WHvszp0p4A6gM8lYDqg= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="PGwVy/Dl"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of 3RogFZwYKCKsdPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3RogFZwYKCKsdPLYUNRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728415716; 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:references:dkim-signature; bh=FPlkG7ZoRlkbHr9vPUwi8+LWYYFCuq+IrymeH+44AKA=; b=QHFhXSCZ1PnrhWDy2nc/ImEGX2aW5YaDQGejetR7lQojA8KYs7d3AZvwrRz5sftEsFaA1J p7VBEn/rnSxHujBuiQPh9Fl9JjLwukuR401ACCAzZvGGRrp5is233lyv1KYPotLO4KakKv r/K3rklLv1BknNNQtU0JumXLm53QsgU= Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-e25cc76cae1so368804276.0 for ; Tue, 08 Oct 2024 12:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728415815; x=1729020615; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=FPlkG7ZoRlkbHr9vPUwi8+LWYYFCuq+IrymeH+44AKA=; b=PGwVy/Dlm9aodOVk89AdOrsUa0p2EWhz7Ax+6N2tSu8lDhUohk7rKFKadEPnptsm/L FpgmobORs1Ho3x/dXwadDkS360kmwvAYHLRseoAKqAjlHPCBOq4qOjN+6U+atbMKrVBT FQN0IgMeDOp8xFG70TlTeV6g4/4St+0GmzmBv0MyneCUUTk3SdxS8ZONU4CNtZ8Wyl9t 2U72/MivlblyLyAu4IwnsI1yBHCW/l7tGvKZd3f+3FuOIOLhMHRRo6lDFOzjn1Lt8j8d lKQgLXs8FZg63kRwYRRphqUSieuP/UPvJUvaPhOZgTaQSYxgaL6/vZpq+mxGG8nWIqaW oScA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728415815; x=1729020615; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FPlkG7ZoRlkbHr9vPUwi8+LWYYFCuq+IrymeH+44AKA=; b=luzqrk5Pj91T17WepC/XqT0UWWeKjqLHyaTL7VIqOzV3l0i5aBygjPSMVsWnSIWoSS w5QHCg/R5fi20lCp4NTmmonL1ZwkkhwaoxEKpcBq+58xkddP4gsn7ONDI41WDJ4wIYmH 9c64NSTnYnlrk4sfLMq2o15uPpvToxUPFvfABkH6LE85K/PRhJ07u8KYwRQOBslUgkgC Zbcvk7pONO4IlPkbA20lJeYHCTyzufyvIuT88PoCdwDDL8Oi/mFYys2TETcMfeslfDl5 Tpg67t+kTEP2sWNRdvI72IFwriL21R361SRf7Tl/xPYfyrFq8bb8Q4Pt7W3phG3difjQ lm3g== X-Forwarded-Encrypted: i=1; AJvYcCUbtH50tAi4IIT9LEeuySIOMp6O0tmp/VRXK4IQw+U8sN1IbIRIPyV0AUMSwaggxF4Z43g+QM3X+A==@kvack.org X-Gm-Message-State: AOJu0YwTE5lg9DlR8N/17pq3XrupHLNUlKZ/PD83SlJ+TwvYFWb2ryHT y/DXTmlzIY442Au+teVQqGAu9THkNbJ7o/e2I9J06rNjXYPUI2acB2z9wuOAAG+w2Fi4PNMY5/k TJQ== X-Google-Smtp-Source: AGHT+IFES2vX7FGCe5EWWJU/+OHopxi8E9cAc1VIHr9YudNnvp5Ss8FEVKKEmYVcxwyacMvNG/vZGf7wOOo= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a25:2d1a:0:b0:e28:e97f:5397 with SMTP id 3f1490d57ef6-e28fe4604a9mr320276.3.1728415814755; Tue, 08 Oct 2024 12:30:14 -0700 (PDT) Date: Tue, 8 Oct 2024 12:30:13 -0700 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [RFC PATCH 30/39] KVM: guest_memfd: Handle folio preparation for guest_memfd mmap From: Sean Christopherson To: Ackerley Tng Cc: quic_eberman@quicinc.com, 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, 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="us-ascii" X-Rspamd-Queue-Id: E669618000C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 5c4ptfozi7ygmxsr5y1eag3ng67roxse X-HE-Tag: 1728415815-304544 X-HE-Meta: U2FsdGVkX19Odyc4mnrdXKbh0At8ZuzSqqRaDXMw0SDtBgg7LQME/MjZLib4pfDBCrXvDNUUyuuDIfZbGYeEmqCq2sr/ydWMX4FeW77rdmYo9z8d4SQ2tEDRt11vXVD5cPCQ41OZBss8MSLIZqTm9jCnH5FNh1qmyNtWeiOhlNOJJWY4CTH1qxEIv2ClJL63TuEc4GN8T4W+THN84jdO2CpdlnUFwyPeyG8f/VMiOT/AW/sjB6zfY4WmCkQFyu6FnlnLq8/vxQz0DPe9upb59nO9vncFhWS9uDf9fJxT8ubV1fH83LllaYR41w121pZXT7oclNlmF3l6fdK8aVegaygwjbxk37i1shyJk09Tt18Fhio8RgfrEQwyilruVP6DpIzv+PeFL1S7Td3+ZfmZmuqG6UcN30jhl66Mdtbf9M++6kQE4dtV8ttc9jxmY2Optp/Rt0fThV1QX9d7LcfMsFe4FH5luIADb1nOVZSpsGwRk1flfhz/Nm3nRauiezmc6oleCEZtfrHNuhtkJFCvvo4aAtlsWqA14T8vq7ryRB5rLXd4mCBzi16ew1yxGOBGsCZVDejXKCF4ABf59eLf87/ITXJuliyBG7GXWWIrChSMHRyPdqaQPNrZ/UUVOlOPDC659iTxmY1tCVHDaAMpGjFueWHfHfnrEQU2RpgYOXi0mQemMCfIn0drN57/mKSvsXgAp797reesRuU3v2NbJaI20WijCPHuKNoZxYV7/nJHUuTYe7cvnb2E5avZZBQM9RTEvHdIyDfhmSLfP4HmrYdqyhJiuGrgqk9EppuJ1JK2PBzl7ikLAtPbeMxhA1T4seSQgb+2icfU1J+1+zmXYJqaQ+/9/80Gf5D/S6sXI8OndJrH5+WA/1tdDoi3Kv03JdsTQCbrGJffRDqBx9TBIgI0R8j5fq6+zRKTPLz0e6qW2Eu2srN/rnBuPJ+jdN3W9dmqZi8HKiXRPFalE+b t7XoVdlW Ek6fPbN+KbaoFfhNzLyb9PsRiNVl/Jh8otzH05je8RI4OgrLvhUhf5PXCOE0Q3DVpq5NR23TsU5mXIZi4bpstBWDOxc1rSex8Axo/xEYjZCkHny/ABrs2555Zu6j2zgWN74Gf2MLQpM9HKACTT20GsS5G0kmMWBfAXia3cXzuerTgLhBv++ustmZpP3h6z/Ra9QXVvqOZuyhhcw/3wZiF7TLpXIi5wXPn6W7hq8RSg8ITLbBbhYRi6TV8iWOlON4KaEcbnHUB3TkSZ3gTk7UyFom55PF6fooeFZm3t/rc/1H3hBlJdf3jud3Rgpg1y51KEysS9ThNHWE/poLdvlU90Fjelq1q2KAMN5THwYW7ee/Qv7j9dHXsaSvBhpHCGxK6S5UWAOIONa5gaWpUV6oRu933NVbwoy7xULlB2B5Vy9FnaARL01qcQKoJkG5MEQ2OXEEYe73XSoWdlPyAqxmaRNe/kVsiz0kCTqqLsb6VenskFy+E97fOMddCT463SQHHbj56SdMuHkkhEUeykh83fViuiR3oG2MxSVBoSF9Hqf6lzZnlIRCAjdgviJOZQZVkgJdNIudNsK/QXvDos8f/qrC5CCMrHotCcvKJHSXFmbbXSTnpGfRsYIsU7Wr17yOJUVJ95INdCaud8B3UqRIm25anziPUK7ZYkR3erk9pAUMDIVQpqtO1SqZw6Aj9y/AfROme+D8J+pYlQMgoH+Z2vcny1OWLc8kO0ooXpfkPxWaooj5qnEvpor5VUw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.009378, 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 Thu, Oct 03, 2024, Ackerley Tng wrote: > Ackerley Tng writes: > > > Elliot Berman writes: > >> From x86 CoCo perspective, I think it also makes sense to not zero > >> the folio when changing faultiblity from private to shared: > >> - If guest is sharing some data with host, you've wiped the data and > >> guest has to copy again. > >> - Or, if SEV/TDX enforces that page is zero'd between transitions, > >> Linux has duplicated the work that trusted entity has already done. > >> > >> Fuad and I can help add some details for the conversion. Hopefully we > >> can figure out some of the plan at plumbers this week. > > > > Zeroing the page prevents leaking host data (see function docstring for > > kvm_gmem_prepare_folio() introduced in [1]), so we definitely don't want > > to introduce a kernel data leak bug here. > > Actually it seems like filemap_grab_folio() already gets a zeroed page. > > filemap_grab_folio() eventually calls __alloc_pages_noprof() > -> get_page_from_freelist() > -> prep_new_page() > -> post_alloc_hook() > > and post_alloc_hook() calls kernel_init_pages(), which zeroes the page, > depending on kernel config. > > Paolo, was calling clear_highpage() in kvm_gmem_prepare_folio() zeroing an > already empty page returned from filemap_grab_folio()? Yes and no. CONFIG_INIT_ON_ALLOC_DEFAULT_ON and init_on_alloc are very much hardening features, not functional behavior that other code _needs_ to be aware of. E.g. enabling init-on-alloc comes with a measurable performance cost. Ignoring hardening, the guest_memfd mapping specifically sets the gfp_mask to GFP_HIGHUSER, i.e. doesn't set __GFP_ZERO. That said, I wouldn't be opposed to skipping the clear_highpage() call when want_init_on_alloc() is true. Also, the intended behavior (or at least, what intended) of kvm_gmem_prepare_folio() was it would do clear_highpage() if and only if a trusted entity does NOT zero the page. Factoring that in is a bit harder, as it probably requires another arch hook (or providing an out-param from kvm_arch_gmem_prepare()). I.e. the want_init_on_alloc() case isn't the only time KVM could shave cycles by not redundantly zeroing memory.