From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 705B03822A6 for ; Fri, 7 Aug 2026 14:26:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786112803; cv=none; b=IbnHejYD/xnC5NU6HfVcDXzhKKsmeXKE681FmmIrCALXFP6Ge5+YF5dBw9s2deIH3P4kGYZmKRwuxY/NKlhr3QTGC1MuNtD7uq0CtIjQ1oT7uhc+dtVzqYjo9iBegnODZXYhnqUi6CiOMGVRvGjVVDwpuOdSBINmqDM9IUEu9ao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786112803; c=relaxed/simple; bh=PioKfhmz231LgFVU/wgzoZZUJb6vgw10xUxgAZqbhNM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=dGtxp5P2NQcu2gH0JCytBVLwbbSsuUYPQ2vSKoA32VS4MBzYQyiLkaeav/vzCrBJpcvh5VA5iG/XA1/7O5OU1ODVxc19FO8LzX7Cc1aQ0Q5tt1zTMic2YB4eFwYKBFT3R30BBBkgN/QLSFqsfxk+Ax6mga1h6RSHU+cQsGfYtpw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=NnPqvb8l; arc=none smtp.client-ip=209.85.210.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NnPqvb8l" Received: by mail-pf1-f199.google.com with SMTP id d2e1a72fcca58-8486ffba174so8115555b3a.1 for ; Fri, 07 Aug 2026 07:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786112800; x=1786717600; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=JwYnx5pOXpjwFV+QWoWnf2v54gIRTTlRhb9BTNCVN4Y=; b=NnPqvb8lHbmRNkp7SoEBmOSvltMODMs6Q3UodeMdchGjpQT7xEiBfOLqgm5BECYot/ K4QPI3ZQA0x+m1bElBN1mgAKzNCZ2yDTcNbMAvWqJCJCZj+Zwm5562lp5vNHGETkPYvR SU4P1ycnRH7P2Jp8BoYxUlgcY9pBsMoDdBU1merN8FxTAE0XlPTq+MrJu8lEcNumbzpl ccR2BgHBKaTwcbyXFRsebCMRpoM6sleMqR/EK1AVwl6ayJUr2pQJSLJYmOjQyhGA5sF1 vaIPNO4jhDmDxGDSAZL9Q21Ufu7kusMcP7zOvtAg+OolKwwe3YfXxXILt87BfRjjT2kB /mRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786112800; x=1786717600; h=content-transfer-encoding:content-type: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 :content-type; bh=JwYnx5pOXpjwFV+QWoWnf2v54gIRTTlRhb9BTNCVN4Y=; b=mntYrXywRyZAiLlcxNxpffqaW7T01eUx+GST+rKVah16yFZqeZ/elzGF02mqx3oCdd bendjQoOMoYd7Cr2D6kxl7bafDUlUnik0Gg5YGulpQrDbtxn7jV2cpuEqeGQTWnOM4PE lUkd3DmCsUQEndQor/fqMcHVCG3NIlKw37eUiv6WiZvXDxv8CIwH8vKCJ7HRPRfWEn3p 3V8AATJsoiMCTdcWWMMSAcSNpS1OvJ1vL5MM/zNcA9+0qEjsPaJTgOXMhvPU0gKZImFQ /EPNypP9C/sb4WGO85bQ/+AI8jhj5DA4KWhbGGWOp0ZK2aOJFAkWvaNJncsFgVxnUL3o YxNw== X-Forwarded-Encrypted: i=1; AHgh+RoUwtOMec1LboReNvNmVlkW0+TBvhxbQZNTPQBM3lbAiA23m0FbPVwb7gMD12gfUgLpg7ObWL+yTnxCNzc=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5zOtSi+/bYNPO4S4dVXV3BGkqBpLcSAj5HYnMWh4+E9PbIHfp K911ov1fu+c1IqDgodtvxuZrLPmNIEybBOkhuc22WcGgzUaCMoXyGPyKcEIIUSfdSldbksuUhxz SyrzOiw== X-Received: from pfam7.prod.google.com ([2002:aa7:8a07:0:b0:847:926b:dc15]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:4b09:b0:842:3a98:b34d with SMTP id d2e1a72fcca58-84f2e032626mr25108022b3a.31.1786112799701; Fri, 07 Aug 2026 07:26:39 -0700 (PDT) Date: Fri, 7 Aug 2026 07:26:39 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-3-6f5729aa9832@google.com> Message-ID: Subject: Re: [PATCH v3 03/26] mm: introduce AS_NO_DIRECT_MAP From: Sean Christopherson To: Yosry Ahmed Cc: Brendan Jackman , Brendan Jackman , Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Vlastimil Babka , Mike Rapoport , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, patrick.roy@linux.dev, Takahiro Itazuri , Andy Lutomirski , David Kaplan , Thomas Gleixner , Patrick Bellasi , Reiji Watanabe , Nikita Kalyazin , Ackerley Tng Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 06, 2026, Yosry Ahmed wrote: > On Thu, Aug 6, 2026 at 5:19=E2=80=AFPM Sean Christopherson wrote: > > > > 2. Always access guest memory through userspace mappings, i.e. thr= ough uaccess. > > > > > > > > #2 sounds nice, but the problem is that it effectively requires han= d-coded assembly > > > > sequences for anything more complex than basic load/store operation= s. Which isn't > > > > a complete non-starter, but it's a pretty big blocker. E.g. see th= e mess that is > > > > record_steal_time(), and then imagine trying to convert something l= ike > > > > nested_vmx_prepare_msr_bitmap() to use uaccess. > > > > > > > > So, unless someone comes up with a clever idea, KVM will need somet= hing GUP-like. > > > > Strictly speaking, it doesn't necessarily need to be exactly GUP, b= ecause KVM could > > > > poke into guest_memfd directly; KVM would "just" need to manually t= rack its own > > > > mappings. > > > > > > Ideally we can have shared infrastructure for this (i.e. the mermap). > > > > > > > But on x86 at least, that's not really a viable option because it o= nly > > > > works for map-rarely, read/write-many use cases. For one-off acces= ses, creating > > > > and destroying (very) shortlived mappings would be too costly, and = so we'd want > > > > those to go through uaccess. > > > > > > Not necessarily (I hope). I think the mermap pre-allocates page table= s > > > (or some of them) and defers some TLB flushes, it's aimed at > > > short-lived mappings (e.g. for read() syscalls to map a file page, > > > copy to buffer, then unmap). > > > > I highly recommend testing shadow paging if you have aspirations of rep= lacing > > the get_user() in FNAME(walk_addr_generic) with an on-demand mapping. = I would > > be (pleasantly) shocked if dynamic mappings can provide acceptable perf= ormance. >=20 > Oh I was thinking of existing cases where KVM uses kernel mappings (e.g. > kvm_vcpu_map()), as these are the ones where KVM uses GUP now, and need t= o > work for AS_NO_DIRECT_MAP to be usable. I assume the get_user() calls are > already a problem for guest_memfd. =20 They aren't. KVM doesn't yet support in-place conversion, so when guest_me= mfd is used for private memory, the backing for shared memory must come from somet= hing other than guest_memfd. If the guest does something to prompt a host/KVM a= ccess to memory that is private or doesn't have a valid backing, then it's either= a guest bug or a host userspace VMM bug. When guest_memfd is being used for shared memory, i.e. was created with GUEST_MEMFD_FLAG_INIT_SHARED, then get_user() Just Works, because again it'= s userspace's responsibility to establish mappings for memory that KVM may ne= ed to access. All of that holds true for when in-place conversion comes along: if get_use= r() hits a fault, either the guest or userspace screwed up. > AS_NO_DIRECT_MAP will surely make it a bigger problem, but not a new one = :P Well, if it disallows GUP, that will be a new problem. > > > > At that point, userspace is basically required to > > > > maintain mappings for all host-accessible guest memory, and if ther= e are userspace > > > > mappings, then not using GUP doesn't make much sense. > > > > > > > > Note, I called out x86 because x86 has the most extensive emulator = and shadow > > > > paging support, which is where the isolated, one-off accesses happe= n in spades. > > > > Other architectures might be able to squeak by without userspace ma= ppings, at > > > > least for now. > > > > > > > > So, in all likelihood, KVM will want GUP. > > > > > > Yeah I am thinking that the check here to disallow GUP completely for > > > unmapped pages is aggressive. Maybe it works for now if KVM does not > > > currently have any use cases for accessing guest_memfd memory. But if= it does > > > (or will very soon), we need to think more about it, otherwise > > > AS_NO_DIRECT_MAP is not really usable for guest_memfd. Since you said= KVM > > > "will want" GUP, I assume it currently doesn't? > > > > Doesn't what? Have GUP? KVM heavily uses GUP, including for guest_mem= fd that > > can be mapped into userspace. >=20 > Your wording made me think that KVM doesn't currently use GUP for > guest_memfd, but I was obviously wrong. So IIUC GUP needs to succeed for > guest_memfd pages with AS_NO_DIRECT_MAP.=20 Yes, though as I said early, it doesn't *have* to be exactly GUP, just some= thing GUP-like. E.g. it could be a new API, if that's easier/cleaner. What I do= n't think is a good idea though is handling this entirely in KVM/guest_memfd. > To actually access the memory, I assume the guest_memfd side will need to > handle this by either using ephemeral mappings (e.g. mermap), restoring a= nd > zapping direct mappings, or using a userspace mapping. I suppose for the > purposes of AS_NO_DIRECT_MAP core support we just need GUP to succeed? And establish a (ephemeral?) kernel mapping, because general users of GUP w= ill expect that they can access the physical memory through the direct map. Th= at's why I didn't want to handle any of this in KVM[*], the rules and handling n= eed to be kernel-wide. [*] https://lore.kernel.org/all/aeemS2wm38Cm4qAf@google.com