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 8482DC3601E for ; Thu, 10 Apr 2025 22:44:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C76E1280142; Thu, 10 Apr 2025 18:44:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFE99280137; Thu, 10 Apr 2025 18:44:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7C9B280142; Thu, 10 Apr 2025 18:44:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 81E9C280137 for ; Thu, 10 Apr 2025 18:44:13 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3A78A1215A9 for ; Thu, 10 Apr 2025 22:44:14 +0000 (UTC) X-FDA: 83319614028.03.8F962D1 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) by imf22.hostedemail.com (Postfix) with ESMTP id 6F278C0002 for ; Thu, 10 Apr 2025 22:44:12 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EL7AZVH1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of 3u0n4ZwsKCHYUWeYlfYsnhaaiiafY.Wigfchor-ggepUWe.ila@flex--ackerleytng.bounces.google.com designates 209.85.210.202 as permitted sender) smtp.mailfrom=3u0n4ZwsKCHYUWeYlfYsnhaaiiafY.Wigfchor-ggepUWe.ila@flex--ackerleytng.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744325052; 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=8q3CiISuCdraqP5NmbHkgBNhRWV9JENCPu8CVDBomok=; b=8RASaoUqnQca8nGQACDWZotqgaQtJWCht62Kj61oHux2l/sdGB9G8Z5rWZkB3DkrdVn0TM hHNu80fofqG0rN8sK9a5H/RtTq1rZ5oA8Gfr814MlC/ud6waaTjslEM7/wPgwazXOIhM7B LRKkzUCsEkA70BdnnVUISOoqBWoFaE8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EL7AZVH1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of 3u0n4ZwsKCHYUWeYlfYsnhaaiiafY.Wigfchor-ggepUWe.ila@flex--ackerleytng.bounces.google.com designates 209.85.210.202 as permitted sender) smtp.mailfrom=3u0n4ZwsKCHYUWeYlfYsnhaaiiafY.Wigfchor-ggepUWe.ila@flex--ackerleytng.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744325052; a=rsa-sha256; cv=none; b=oiBYveLTi9ofdPyMOybPW/REEv1KzwmTzeiZmOwI4AIzuF8sF8e1272i+xL3KTQyfrrhWf vSsWDb395C8k+DJ3NfylVTZpEcPqvGfNErEZt6xRQ/o2ffDqEzDeyuFvOBcYvcQLuj+AkP fQfpi37x9Kw/smuB0Cnimq6g9dRLUcA= Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-736cd27d51fso1132504b3a.2 for ; Thu, 10 Apr 2025 15:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744325051; x=1744929851; 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=8q3CiISuCdraqP5NmbHkgBNhRWV9JENCPu8CVDBomok=; b=EL7AZVH1kjWpbyAySG4X37fqEZYrqFucLju7gO6F/fj7FBI0rtBusNkWmcsxfLVKZj TF7mslOxBtBVTvxrzgdeC25G9hqjqQbVRlpi5zV0DOFfQdupjeX2DpYvlzral2ZJq+Xw Je7niBYtzOrIdraIugaQYFj4il9EEEvkZ5rqdK5CCsTdqeEEp8zZwX5IB3FhCKacW7pN hdUkWFlh6lvyHvn0LYpx8zgPXoS4zVU4oymsAVLu7alg83djJKdBpqI7Ct7z4J9uKGD3 EZfvASzn1qEZNNWncw8ccLadVqDvxGeaJyg2OgDiTJUfdsyKWHCsHRsaVrBggAyhaljA lfWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744325051; x=1744929851; 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=8q3CiISuCdraqP5NmbHkgBNhRWV9JENCPu8CVDBomok=; b=Ti2h5JKJGKHM10dibulxePzcnXB4rPULiX9sKhksjubvz377JGYR2RCY3mupx2cDgK fNQhqZLrRgAx8c6oaWCuAWde5UzAgootteuBJ3sJOOc+ZER+LkN9UeM87wIIT02cuP0h YwJzc6uqvcxCVG7V83EV2IArH7inyhmvH5UO7Gbn8v3u8gDiV/t99d6NNaOKrH0ZtMXk LPH7xLeCYzQI+eIlHFUJVd9GVfEscD5AGDNhJyt9rcpczuimUK2xaRz8aEmHPhV2M8kS aTdwLE9JjMUNLP2BOhjeZ1r2Yfb0MEZVXpiy+J5vmq/3Pe166DFGoCpEPh5o7QH7+a+9 16tw== X-Forwarded-Encrypted: i=1; AJvYcCUn5vCEBQNuU348Hn8Glx43Gm80mexH8p9nJJN/n6WmLLJ03NjK3UVeQzPKDg3ZK/mf/H51PO+mMg==@kvack.org X-Gm-Message-State: AOJu0YzhJP/kaGsbe8ofoEVHVUAsJ1XDp/AbVTK2ezSunklnqDr+O/QK MnNHYcAkieDQ3oXYn8xHkxeijl5uwMOGCR+STKrUbyweS1WnxeqzaK/ZPPT9tQFVn/Fz/GjdELl 6e2xajOOGVtyPyKPdwFyJCA== X-Google-Smtp-Source: AGHT+IEYlt0gVCvlaMwf0civi1/Gt1C+rN2vsEcK26X/Wy47JZJtnV7Cpm0OLOPQfOn3q9dHvyxaDidMfs1bvz2+7A== X-Received: from pfbi30.prod.google.com ([2002:a05:6a00:af1e:b0:739:4935:6146]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3a01:b0:736:69aa:112c with SMTP id d2e1a72fcca58-73bd11e26d6mr589808b3a.9.1744325051085; Thu, 10 Apr 2025 15:44:11 -0700 (PDT) Date: Thu, 10 Apr 2025 15:44:09 -0700 In-Reply-To: Mime-Version: 1.0 References: <20250318161823.4005529-1-tabba@google.com> <20250318161823.4005529-4-tabba@google.com> Message-ID: Subject: Re: [PATCH v7 3/9] KVM: guest_memfd: Allow host to map guest_memfd() pages From: Ackerley Tng To: Shivank Garg , Fuad Tabba , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org Cc: 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, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@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, peterx@redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Stat-Signature: 6jsybcdid4ug56bf9a5fwcci5uhm6hyh X-Rspam-User: X-Rspamd-Queue-Id: 6F278C0002 X-HE-Tag: 1744325052-240434 X-HE-Meta: U2FsdGVkX1++4mZD5O6ROiH0itRo9dJQCX6cDeHUuXPuy/F0AAiFhNeBJ+yliXSsbZRsTYLCe/TXa9A7aNRCqVsWeUvjTDU/UtJKgb639NJdNuvI1DUuitGfjmkAw0CVo+TfaT66I33EuLdD0L/NJgrpv73Fo13dxfwo+edIgPFUeVRu6r+O1BwyuUwcw69sVbfa9ymhwGe010JtVznFX4BHCu+G2ZZmEqO3IJ2IzjKeeJRqJzpfNEUXD/6TusCUzIRXxOFD8iaZM6OvhBr91yfSeG90sELQ3xE59WlkOuKYFZhiFY/2HNCqNusepUhhBUBFrzFBl+JbkP83IowIbeHA7j0AtN16bnVtn9bJgJEMX0xgvc3bpGJHxVWoZFMEM67Ghxd9yzfhCct1vcoCNWNe/cDqoHWFRIDZUHyxLr3jeTNcVjXDoJTlg681q0peAZ0RCZ4VlWwHcDxs2i9puMhviANFSMatdNGmp1ZXWfOIoJotflq/o65w1fi2SKKDAIoWMqyQ/WPQXn/iGwXNVTHORVw8zSBBAc7okH6mffq/3QXIJtv0jRNcPD33BXz9REll+6ws79zIE1+HKRLiMt2CwhTZHNcBAB5YM63okvONov41hoDzCCjoDCFtMeRa6eZ2R5xscWRksMav1b/q3+LzhAR87ecwPibUtEUqUK3acndVtV8Ps1RpYIPL+DolCH5Uf5tpV0EPs0ms/3rFJJbfH7TDLtg+mmAawu1+ii2q7lJuBmi08atQpUtZTutFOCgk0zcxNLUSW8x9egDO0BcSewPEsTjSNmzuFRK4I0/1umUa5vuHy2gzuNpKVl25V8hzQTKWy9ENrQVrDAPYmCv5Umt0k7WVBbOqK42a3YbGMtMFz0zbRVgfMaLamj9eSMLzHvYDKHJkJe1l8R9zFBoSH/c4I+F5OdE0EW0xYA61WXH7NcH+HZERNnskUtA+BeVKz1ugw43Lpsy1EsG 2MrgeFBi 5g2Jar+kzDnwhfMeHZoZpZfc+g4m38LBQTTTO3Fq70pGg36EQjnFt7KmqD9v5Yx41JXcLtm4vBkp71SpQOya8HVG9MXVg18VUh69M1Uk1wWIzq/cAZBm9/maCBpVn5XQKLpqLolMURoOMghSGZxABHBYnFbCP9WYcLdBLGYh5Cs/u19Nt5mGFatS2/dBFMeZITOzjPzrWhZnQVd+5AzZZcJJnsXxohxaOhJVqt8kuczLoBwRjZBYF7y8y7Movs6qxoirBqF3b7kCRBmece5s9rxw3Aaz7O2sGX1l/oXEYcaS6fs6YupqJReSOa3lKHoRZv+wKWboKTDZ6EVbgswG6lgRgQf/xY6fArcleLX9uZhh42ueBtdp2FsvKVUBgvcKudHkzKKuePWwnTe8jKtDx6gYA+HIzYBCbJnwS/amB85iA/VcbkVmC4j+6WPNYzVIyiM+J9gZX4n/g52ZcPRsCGeVHOabubq8QJoOVu6R7Pl96G8kP5Tb+kaJ4vKx3RbfYicqavJCv1ZcLasp/JU4bNEVBQZ43XQ63VF3upnAReMZe3n5fYeeh+lRv8HLKa8zInaksk2t4wgnS0KC31dApa0tnBwZMZ8HfOipkgqhh9x+Gkl8LVVIHDa4fqwm7EG/LiDef47uTnBv+S5xWjqSNEH1F4eFJnl0PfsmN4bT5WJZ6wuxc6liFMcaeTgm6RqnV8OtG4KEhmSLq1gI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Shivank Garg writes: > On 4/8/2025 10:28 PM, Ackerley Tng wrote: >> Shivank Garg writes: >> >>> Hi Fuad, >>> >>> On 3/18/2025 9:48 PM, Fuad Tabba wrote: >>>> Add support for mmap() and fault() for guest_memfd backed memory >>>> in the host for VMs that support in-place conversion between >>>> shared and private. To that end, this patch adds the ability to >>>> check whether the VM type supports in-place conversion, and only >>>> allows mapping its memory if that's the case. >>>> >>>> Also add the KVM capability KVM_CAP_GMEM_SHARED_MEM, which >>>> indicates that the VM supports shared memory in guest_memfd, or >>>> that the host can create VMs that support shared memory. >>>> Supporting shared memory implies that memory can be mapped when >>>> shared with the host. >>>> >>>> This is controlled by the KVM_GMEM_SHARED_MEM configuration >>>> option. >>>> >>>> Signed-off-by: Fuad Tabba >>> >>> ... >>> ... >>>> + >>>> +static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma) >>>> +{ >>>> + struct kvm_gmem *gmem = file->private_data; >>>> + >>>> + if (!kvm_arch_gmem_supports_shared_mem(gmem->kvm)) >>>> + return -ENODEV; >>>> + >>>> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) != >>>> + (VM_SHARED | VM_MAYSHARE)) { >>>> + return -EINVAL; >>>> + } >>>> + >>>> + file_accessed(file); >>> >>> As it is not directly visible to userspace, do we need to update the >>> file's access time via file_accessed()? >>> >> >> Could you explain a little more about this being directly visible to >> userspace? >> >> IIUC generic_fillattr(), which guest_memfd uses, will fill stat->atime >> from the inode's atime. file_accessed() will update atime and so this >> should be userspace accessible. (Unless I missed something along the way >> that blocks the update) >> > > By visibility to userspace, I meant that guest_memfd is in-memory and not > directly exposed to users as a traditional file would be. shmem is also in-memory and uses updates atime, so I guess being in-memory doesn't mean we shouldn't update atime. guest_memfd is not quite traditional, but would the mmap patches Fuad is working on now qualify the guest_memfd as more traditional? > > Yes, theoretically atime is accessible to user, but is it actually useful for > guest_memfd, and do users track atime in this context? In my understanding, > this might be an unnecessary unless we want to maintain it for VFS consistency. > > My analysis of the call flow: > fstat() -> vfs_fstat() -> vfs_getattr() -> vfs_getattr_nosec() -> kvm_gmem_getattr() > I couldn't find any kernel-side consumers of inode's atime or instances where > it's being used for any internal purposes. > > Searching for examples, I found secretmem_mmap() skips file_accessed(). > I guess I'm okay both ways, I don't think I have a use case for reading atime, but I assumed VFS consistency is a good thing. > > Also as side note, I believe the kvm_gmem_getattr() ops implementation > might be unnecessary here. > Since kvm_gmem_getattr() is simply calling generic_fillattr() without > any special handling, couldn't we just use the default implementation? > > int vfs_getattr_nosec(const struct path *path, struct kstat *stat, > u32 request_mask, unsigned int query_flags) > { > ... > if (inode->i_op->getattr) > return inode->i_op->getattr(idmap, path, stat, > request_mask, > query_flags); > > generic_fillattr(idmap, request_mask, inode, stat); > return 0; > } I noticed this too. I agree that we could actually just use generic_fillattr() by not specifying ->getattr(). > > I might be missing some context. Please feel free to correct me > if I've misunderstood anything. > > Thanks, > Shivank > >>>> + vm_flags_set(vma, VM_DONTDUMP); >>>> + vma->vm_ops = &kvm_gmem_vm_ops; >>>> + >>>> + return 0; >>>> +} >>>> +#else >>>> +#define kvm_gmem_mmap NULL >>>> +#endif /* CONFIG_KVM_GMEM_SHARED_MEM */ >>>> + >>>> static struct file_operations kvm_gmem_fops = { >>>> + .mmap = kvm_gmem_mmap, >>>> .open = generic_file_open, >>>> .release = kvm_gmem_release, >>>> .fallocate = kvm_gmem_fallocate, >>> >>> Thanks, >>> Shivank