From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Mon, 6 Nov 2023 07:43:07 -0800 Subject: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory In-Reply-To: References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-17-seanjc@google.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, Nov 04, 2023, Xu Yilun wrote: > > +KVM_SET_USER_MEMORY_REGION2 is an extension to KVM_SET_USER_MEMORY_REGION that > > +allows mapping guest_memfd memory into a guest. All fields shared with > > +KVM_SET_USER_MEMORY_REGION identically. Userspace can set KVM_MEM_PRIVATE in > > +flags to have KVM bind the memory region to a given guest_memfd range of > > +[guest_memfd_offset, guest_memfd_offset + memory_size]. The target guest_memfd > ^ > The range end should be exclusive, is it? Yes, that should be a ')', not a ']'. > > +static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags) > > +{ > > + const char *anon_name = "[kvm-gmem]"; > > + struct kvm_gmem *gmem; > > + struct inode *inode; > > + struct file *file; > > + int fd, err; > > + > > + fd = get_unused_fd_flags(0); > > + if (fd < 0) > > + return fd; > > + > > + gmem = kzalloc(sizeof(*gmem), GFP_KERNEL); > > + if (!gmem) { > > + err = -ENOMEM; > > + goto err_fd; > > + } > > + > > + /* > > + * Use the so called "secure" variant, which creates a unique inode > > + * instead of reusing a single inode. Each guest_memfd instance needs > > + * its own inode to track the size, flags, etc. > > + */ > > + file = anon_inode_getfile_secure(anon_name, &kvm_gmem_fops, gmem, > > + O_RDWR, NULL); > > + if (IS_ERR(file)) { > > + err = PTR_ERR(file); > > + goto err_gmem; > > + } > > + > > + file->f_flags |= O_LARGEFILE; > > + > > + inode = file->f_inode; > > + WARN_ON(file->f_mapping != inode->i_mapping); > > Just curious, why should we check the mapping fields which is garanteed in > other subsystem? Mostly to document the behavior. The vast majority of folks that read this code will be KVM developers, not file systems developers, and will likely have no clue about the relationship between f_mapping and i_mapping. And in the extremely unlikely scenario that anon_inode_getfile_secure() no longer sets f_mapping, a WARN detects the issue whereas a comment does not. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (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 BD1D018AEB for ; Mon, 6 Nov 2023 15:43:23 +0000 (UTC) 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="aBAyS1tX" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-5a8d9dcdd2bso93832537b3.2 for ; Mon, 06 Nov 2023 07:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699285403; x=1699890203; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=aBAyS1tXClLkh8Ii9//sHtAv8qZWjwSEzNpd74Of9DUZeOCu/AO7v/lZqoce8RoYaA Fj0eCMg5U+71bzSsyFVhUuYFeolMHzcZHAopWMIWArSGQDd8AOLbjR8evZY01UbYNCy/ +E+Fjcd217ffQMt2T33Pihh0gp+SQiwhPTTsMasHEM3XayulF1i0DuAZdUhfM5Ys+Xwa aYuNVDu1+2WufgV4nPez2G7EJ8p2mtMkH3gokVA/FRyMWFbA4NphbvDxEef0yo5yCJeN 6WgA/ftWW2V+kiB2XufymV/uhywaNBOHwMU3WM6bM1GTegnCspeCa4EuwSb7sMp/4IhI +4jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699285403; x=1699890203; 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=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=Pma+fp8teET+N8bWzhSRBjgn5728pBu0j93sw93zcgP3B8PNPODJtysl/j1eKEwxoZ hw8LAeLNAMEEhRsAjpCMW2Q4k6itkpBB/AtcvyajwItbJXgjZ8c2rGespq3qZAv+L6aG lUf1a09J8cr80vC0S/DWW4Z0H+AwFGZ5zG19412GcD+ino0DL/6zAfdFMYLAXMsU2PlW Ek5HGhfauQ2Fird/cleVngyPUesUh26xXnpoS5WY/U8AiWBgRK6BJTcSZXHUBt6HeLpt h0IN9vHwZNYpgXtpuL+OiZWP4rYnyNuJNMM8myOu5tzRvG3Zw8nC/BIR35I8sf2lxxQ6 iqIw== X-Gm-Message-State: AOJu0YwI5zrBbtxWYrLsOh7s09OEA5Pr8msxFj51UkOS8TtmLLnSGkCW rhmWeNnTnF6HSWoq55Pgrs8RfEf1zyU= X-Google-Smtp-Source: AGHT+IFZU6oilNAmMp5GLulg+dwoZ1zspXQbywwTDejvG8kP1K7yDCwH0QkLRrw/RyNVPmFev9uMuH6PQSU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ce94:0:b0:da0:3bea:cdc7 with SMTP id x142-20020a25ce94000000b00da03beacdc7mr527390ybe.2.1699285402751; Mon, 06 Nov 2023 07:43:22 -0800 (PST) Date: Mon, 6 Nov 2023 07:43:07 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-17-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xu Yilun Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Xiaoyao Li , Xu Yilun , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , "=?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?=" , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Content-Type: text/plain; charset="us-ascii" On Sat, Nov 04, 2023, Xu Yilun wrote: > > +KVM_SET_USER_MEMORY_REGION2 is an extension to KVM_SET_USER_MEMORY_REGION that > > +allows mapping guest_memfd memory into a guest. All fields shared with > > +KVM_SET_USER_MEMORY_REGION identically. Userspace can set KVM_MEM_PRIVATE in > > +flags to have KVM bind the memory region to a given guest_memfd range of > > +[guest_memfd_offset, guest_memfd_offset + memory_size]. The target guest_memfd > ^ > The range end should be exclusive, is it? Yes, that should be a ')', not a ']'. > > +static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags) > > +{ > > + const char *anon_name = "[kvm-gmem]"; > > + struct kvm_gmem *gmem; > > + struct inode *inode; > > + struct file *file; > > + int fd, err; > > + > > + fd = get_unused_fd_flags(0); > > + if (fd < 0) > > + return fd; > > + > > + gmem = kzalloc(sizeof(*gmem), GFP_KERNEL); > > + if (!gmem) { > > + err = -ENOMEM; > > + goto err_fd; > > + } > > + > > + /* > > + * Use the so called "secure" variant, which creates a unique inode > > + * instead of reusing a single inode. Each guest_memfd instance needs > > + * its own inode to track the size, flags, etc. > > + */ > > + file = anon_inode_getfile_secure(anon_name, &kvm_gmem_fops, gmem, > > + O_RDWR, NULL); > > + if (IS_ERR(file)) { > > + err = PTR_ERR(file); > > + goto err_gmem; > > + } > > + > > + file->f_flags |= O_LARGEFILE; > > + > > + inode = file->f_inode; > > + WARN_ON(file->f_mapping != inode->i_mapping); > > Just curious, why should we check the mapping fields which is garanteed in > other subsystem? Mostly to document the behavior. The vast majority of folks that read this code will be KVM developers, not file systems developers, and will likely have no clue about the relationship between f_mapping and i_mapping. And in the extremely unlikely scenario that anon_inode_getfile_secure() no longer sets f_mapping, a WARN detects the issue whereas a comment does not. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2FE9DC4332F for ; Mon, 6 Nov 2023 15:43:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=7fS/vES14BXrZL0Medsbkkj6jvzU3+WMM1yW7sWJCEA=; b=SRP9T48WFZY4orhfIKeXtv01vd HxUo4hckGNqerc5l4lUbLxiYb+0q6B2xf9PeREw5u03whNbxBesGSO/bNJ8Z0LS0OvWrdATIF/5+m 1MlcItE0gIpkMXmuH3eZuIeJvUQDlc1HPRBDVdC73MpAeRBnCTpxa4leqO+nSLGAH6aWcfzyrTMje VDSv6lZls84096kqNgvWln9OAKOReQ3vyOyZWl1oXeuf/bYOICbzEsUu5NMSHwlGavenuVsh1qrgy XdulI3l826iaHER3vYtTdyU+je8DNEu8nbbIQol18NuvFxP9P5Jo1QMnQ2S5YJfQ4iYknYMuUVfN6 XidnUAHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r01lA-00H0oo-1a; Mon, 06 Nov 2023 15:43:28 +0000 Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r01l7-00H0mx-2K for linux-riscv@lists.infradead.org; Mon, 06 Nov 2023 15:43:27 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5afa071d100so94074167b3.1 for ; Mon, 06 Nov 2023 07:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699285403; x=1699890203; darn=lists.infradead.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=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=QrzPLK3IWq94auIC/393/M34mlrwLbk2pJx3FhssHzES1ReGmrL2chu3zyJFs15ER3 JXrIwDDzkuBi8LHoWXOSiD5qk3/w9rWaZPf7qnv3oBNRLX0mW9GxROhYPSZAhruENtKZ hYcqdal6z4JRrX6beG5hLjeadmhrkzRTFSlJxIYKK9KIOFiAAxv7vGIEDiayxBOqECp9 uA9oQiVV62YgGbGXfM9pODMHhl987+QNzThaRKOWWLoElXji2eE07Dv+VoKG4SyDOFUz FORzkJk6787JE1pRMMDt/vY9nwXB4sU110g/GbsW4RS0YoZNk3PGXNEzk+Qb8+NJy8Rl M2pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699285403; x=1699890203; 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=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=ID7NkYgaKTiWQmboNS9yYcPM8WXxMeV4Pl6HY8f9Wy2L+YMNHZZ5+TJXCYNBLHjhb6 ZVUlkfjCF6sBkQ/o9KXX9QtXmJ0tpiCqb2hvrl8PIMgI7drb+D9su1dqfSLH7EXwN4JK H5OBH2vyDXDbY01GLJywr7mZaQJYNCHoc8TXI8kRU7YdEk6+92E07Akn+PjhJwi8Yr7h yVIymmaLeuwzDMhfeE4lZ7fML1rXL8aJdBNJkcUjht3rL9F/cpxwxk6qdbSuu63zXwgw eqUMoumWejhDImFdXUE3ePzLJZFOS53kWX7QK6SgIj39VaN2ULLlmITfpqAxbStDWKJ0 8QzA== X-Gm-Message-State: AOJu0YxAyZE0jynEMCg9YRwsEU1LP2sO2Wh1BX+bCJ27eFY3pMeb4x/O 2JqUlDMTdqAhJ4LxlL8Vb7i5ntNXY1w= X-Google-Smtp-Source: AGHT+IFZU6oilNAmMp5GLulg+dwoZ1zspXQbywwTDejvG8kP1K7yDCwH0QkLRrw/RyNVPmFev9uMuH6PQSU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ce94:0:b0:da0:3bea:cdc7 with SMTP id x142-20020a25ce94000000b00da03beacdc7mr527390ybe.2.1699285402751; Mon, 06 Nov 2023 07:43:22 -0800 (PST) Date: Mon, 6 Nov 2023 07:43:07 -0800 In-Reply-To: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-17-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xu Yilun Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Xiaoyao Li , Xu Yilun , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , "=?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?=" , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231106_074325_780319_91404202 X-CRM114-Status: GOOD ( 17.75 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Sat, Nov 04, 2023, Xu Yilun wrote: > > +KVM_SET_USER_MEMORY_REGION2 is an extension to KVM_SET_USER_MEMORY_REGION that > > +allows mapping guest_memfd memory into a guest. All fields shared with > > +KVM_SET_USER_MEMORY_REGION identically. Userspace can set KVM_MEM_PRIVATE in > > +flags to have KVM bind the memory region to a given guest_memfd range of > > +[guest_memfd_offset, guest_memfd_offset + memory_size]. The target guest_memfd > ^ > The range end should be exclusive, is it? Yes, that should be a ')', not a ']'. > > +static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags) > > +{ > > + const char *anon_name = "[kvm-gmem]"; > > + struct kvm_gmem *gmem; > > + struct inode *inode; > > + struct file *file; > > + int fd, err; > > + > > + fd = get_unused_fd_flags(0); > > + if (fd < 0) > > + return fd; > > + > > + gmem = kzalloc(sizeof(*gmem), GFP_KERNEL); > > + if (!gmem) { > > + err = -ENOMEM; > > + goto err_fd; > > + } > > + > > + /* > > + * Use the so called "secure" variant, which creates a unique inode > > + * instead of reusing a single inode. Each guest_memfd instance needs > > + * its own inode to track the size, flags, etc. > > + */ > > + file = anon_inode_getfile_secure(anon_name, &kvm_gmem_fops, gmem, > > + O_RDWR, NULL); > > + if (IS_ERR(file)) { > > + err = PTR_ERR(file); > > + goto err_gmem; > > + } > > + > > + file->f_flags |= O_LARGEFILE; > > + > > + inode = file->f_inode; > > + WARN_ON(file->f_mapping != inode->i_mapping); > > Just curious, why should we check the mapping fields which is garanteed in > other subsystem? Mostly to document the behavior. The vast majority of folks that read this code will be KVM developers, not file systems developers, and will likely have no clue about the relationship between f_mapping and i_mapping. And in the extremely unlikely scenario that anon_inode_getfile_secure() no longer sets f_mapping, a WARN detects the issue whereas a comment does not. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B5619C4332F for ; Mon, 6 Nov 2023 15:44:22 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=kgJoDXVa; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4SPFyX6Lp5z3cN4 for ; Tue, 7 Nov 2023 02:44:20 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=kgJoDXVa; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::1149; helo=mail-yw1-x1149.google.com; envelope-from=3mgljzqykdamvhdqmfjrrjoh.frpolqx0ssf-ghyolvwv.r2odev.ruj@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4SPFxc5DR3z2ytV for ; Tue, 7 Nov 2023 02:43:30 +1100 (AEDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5a839b31a0dso94195147b3.0 for ; Mon, 06 Nov 2023 07:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699285403; x=1699890203; darn=lists.ozlabs.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=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=kgJoDXVaOjpDAuNUOcsSyit47AvHaodq7dcwn4QYtal5Swy4/VqjPbkgxp72Lptdiz 5tyJt6O7CdcJCbB+kUxXUjt3li3cjUACnr+uoP6HKylKh9wmQobZQNkK4CHpJfNdvfxC dloNaGM7aF3UotcKjnMr28YNB3SFQm1QHx903eRK2i1cZ9FfVTvlLMKRYywBUk5auoE6 K9MJB2F0xQeHeSLDWMYwR6oB0nYxlWzNjZ/CPqR9tY+JopCI4yYLlsdAuKQvEMNP9cjW tN+UHHtYGSatKEEv1e7y5gh4nTgz/ZXMCoxk+dh3kG7bQloAo8nJql3BW6lM3artZ5Mt p1yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699285403; x=1699890203; 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=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=tEmsKLwNJHkvYiN1T0P73lcCiBPFwq7ZLzqVfOuvyRrhE+/3komim1pYOH1ZhomPUu PNw/QkJayP55dpMmqiIsVkKm/VsmfSXVJOVt2dxMUdj7s+TjdLMEz0J9sNeS9n8diB+X D/GYgwmIdIO/nj7FxFs/vLwJ8SfzzFkaOJwMSCLkoIy+8ZsQktiayhFZS1ItMFuskq92 jgrZtc4O25cMzuqPUiaOM20yhliHd+1TivGhiR5gRs2T8HiBYik8dUdwTyC3pcBn4kKl XUi+yWH0Mf9edGiDGwVrTo5T25pWS1CEIfcmP2YCmaLeGvdncRo8Taz10i7p5JgM0qNH f6Xg== X-Gm-Message-State: AOJu0YwM/nKD/lPf4Bp6r1YSAf6zCzcdyc9kZzp3ki7GkxQb0TTDnRld OORqcfoanfJy0CQb869P8hpM+nVnMwA= X-Google-Smtp-Source: AGHT+IFZU6oilNAmMp5GLulg+dwoZ1zspXQbywwTDejvG8kP1K7yDCwH0QkLRrw/RyNVPmFev9uMuH6PQSU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ce94:0:b0:da0:3bea:cdc7 with SMTP id x142-20020a25ce94000000b00da03beacdc7mr527390ybe.2.1699285402751; Mon, 06 Nov 2023 07:43:22 -0800 (PST) Date: Mon, 6 Nov 2023 07:43:07 -0800 In-Reply-To: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-17-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xu Yilun Content-Type: text/plain; charset="us-ascii" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chao Peng , linux-riscv@lists.infradead.org, Isaku Yamahata , Marc Zyngier , Huacai Chen , Xiaoyao Li , "Matthew Wilcox \(Oracle\)" , Wang , Fuad Tabba , Yu Zhang , Maciej Szmigiero , Albert Ou , Vlastimil Babka , Michael Roth , Ackerley Tng , Alexander Viro , Paul Walmsley , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Isaku Yamahata , Christian Brauner , Quentin Perret , L iam Merwick , linux-mips@vger.kernel.org, Oliver Upton , David Matlack , Jarkko Sakkinen , Palmer Dabbelt , "Kirill A . Shutemov" , kvm-riscv@lists.infradead.org, Anup Patel , linux-fsdevel@vger.kernel.org, Paolo Bonzini , Andrew Morton , Vishal Annapurve , linuxppc-dev@lists.ozlabs.org, Xu Yilun , Anish Moorthy Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sat, Nov 04, 2023, Xu Yilun wrote: > > +KVM_SET_USER_MEMORY_REGION2 is an extension to KVM_SET_USER_MEMORY_REGION that > > +allows mapping guest_memfd memory into a guest. All fields shared with > > +KVM_SET_USER_MEMORY_REGION identically. Userspace can set KVM_MEM_PRIVATE in > > +flags to have KVM bind the memory region to a given guest_memfd range of > > +[guest_memfd_offset, guest_memfd_offset + memory_size]. The target guest_memfd > ^ > The range end should be exclusive, is it? Yes, that should be a ')', not a ']'. > > +static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags) > > +{ > > + const char *anon_name = "[kvm-gmem]"; > > + struct kvm_gmem *gmem; > > + struct inode *inode; > > + struct file *file; > > + int fd, err; > > + > > + fd = get_unused_fd_flags(0); > > + if (fd < 0) > > + return fd; > > + > > + gmem = kzalloc(sizeof(*gmem), GFP_KERNEL); > > + if (!gmem) { > > + err = -ENOMEM; > > + goto err_fd; > > + } > > + > > + /* > > + * Use the so called "secure" variant, which creates a unique inode > > + * instead of reusing a single inode. Each guest_memfd instance needs > > + * its own inode to track the size, flags, etc. > > + */ > > + file = anon_inode_getfile_secure(anon_name, &kvm_gmem_fops, gmem, > > + O_RDWR, NULL); > > + if (IS_ERR(file)) { > > + err = PTR_ERR(file); > > + goto err_gmem; > > + } > > + > > + file->f_flags |= O_LARGEFILE; > > + > > + inode = file->f_inode; > > + WARN_ON(file->f_mapping != inode->i_mapping); > > Just curious, why should we check the mapping fields which is garanteed in > other subsystem? Mostly to document the behavior. The vast majority of folks that read this code will be KVM developers, not file systems developers, and will likely have no clue about the relationship between f_mapping and i_mapping. And in the extremely unlikely scenario that anon_inode_getfile_secure() no longer sets f_mapping, a WARN detects the issue whereas a comment does not. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 58557C4332F for ; Mon, 6 Nov 2023 15:44:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=YgpQi5Qx0GVn2d+EGbtdvagkL52PeROU3tVk2zUONbE=; b=RBvehUblE9ZhvEinC4Sqq5STpU GlYF6iAsuBrw3AT1WAK/tupsNNh3lwvd802SebB71gUqjfZFWa0pmYpX4AsSdJOpq9rD3wRPUu8ys S3uUgpuqvuG4cS8/rgXaAzWVtn8WoRWmuibA1Lcns9n08VLs5+OAnb2lINC1LycVPMvZs/VS/ti29 sNymForPD+W6hk3sk/ES/Zpc10E09/+AaJ5TDaZmxSrYv3gw+aRMN+UMvCgB93NTF1c50kNQ43cvI 1eSTQrYIRKYNMtO6ZDK5J3PufcwTL8f7hr1zL2IIqr4Om00lIM32fqx3hYNk0U95/4ZyoNDCMM937 RlXHG5Ug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r01lB-00H0oy-0Y; Mon, 06 Nov 2023 15:43:29 +0000 Received: from mail-yw1-x1149.google.com ([2607:f8b0:4864:20::1149]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r01l8-00H0n0-0X for linux-arm-kernel@lists.infradead.org; Mon, 06 Nov 2023 15:43:27 +0000 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5a8d9dcdd2bso93832617b3.2 for ; Mon, 06 Nov 2023 07:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699285403; x=1699890203; darn=lists.infradead.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=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=QrzPLK3IWq94auIC/393/M34mlrwLbk2pJx3FhssHzES1ReGmrL2chu3zyJFs15ER3 JXrIwDDzkuBi8LHoWXOSiD5qk3/w9rWaZPf7qnv3oBNRLX0mW9GxROhYPSZAhruENtKZ hYcqdal6z4JRrX6beG5hLjeadmhrkzRTFSlJxIYKK9KIOFiAAxv7vGIEDiayxBOqECp9 uA9oQiVV62YgGbGXfM9pODMHhl987+QNzThaRKOWWLoElXji2eE07Dv+VoKG4SyDOFUz FORzkJk6787JE1pRMMDt/vY9nwXB4sU110g/GbsW4RS0YoZNk3PGXNEzk+Qb8+NJy8Rl M2pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699285403; x=1699890203; 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=ABS8rPoBy1ITQ62kUEvxWovIfmSWeQOAvNCpebOJLoI=; b=pVLmNB0CVkg5yWbNnK2ut3XAJgGdNy/J677P0p69wp3ASc89rIcKKANXYjSi9g39TB WtKkbCvQNhdHzvnemBnn+4/cnBQZB93H2MQtyvZweuPuC00NOjMQw52w2mGxkWwYJdlF f2qpQ2BgbYfY4svyJhQjOaOiVHhwFGFRzmS9zR+yeiUkBEs6GVtloBHmTsNO3HLBMZGl JmB8tDJqHwCuHX3MSIqHbTuv0BZlbF3W0Fwxp7j3VGKQHCxh9zTyN5UsEowLRMRcva3h FvRsihVInmjLmQ/Z2llWDJbiqPrL99pimjjXjqxZ3UYS/6+VUt3BualpDI9ue6/viG0q B6+w== X-Gm-Message-State: AOJu0YxuJaJ7A1f1qiI2Dei2PWQanAudCIX/6BMfCL3h/8tLBoXA+Xdu WeueCccLJwrTD4Qsuomq1J8HhtHG6W0= X-Google-Smtp-Source: AGHT+IFZU6oilNAmMp5GLulg+dwoZ1zspXQbywwTDejvG8kP1K7yDCwH0QkLRrw/RyNVPmFev9uMuH6PQSU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ce94:0:b0:da0:3bea:cdc7 with SMTP id x142-20020a25ce94000000b00da03beacdc7mr527390ybe.2.1699285402751; Mon, 06 Nov 2023 07:43:22 -0800 (PST) Date: Mon, 6 Nov 2023 07:43:07 -0800 In-Reply-To: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-17-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xu Yilun Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Xiaoyao Li , Xu Yilun , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , "=?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?=" , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231106_074326_203433_8EC8D1B4 X-CRM114-Status: GOOD ( 19.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Nov 04, 2023, Xu Yilun wrote: > > +KVM_SET_USER_MEMORY_REGION2 is an extension to KVM_SET_USER_MEMORY_REGION that > > +allows mapping guest_memfd memory into a guest. All fields shared with > > +KVM_SET_USER_MEMORY_REGION identically. Userspace can set KVM_MEM_PRIVATE in > > +flags to have KVM bind the memory region to a given guest_memfd range of > > +[guest_memfd_offset, guest_memfd_offset + memory_size]. The target guest_memfd > ^ > The range end should be exclusive, is it? Yes, that should be a ')', not a ']'. > > +static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags) > > +{ > > + const char *anon_name = "[kvm-gmem]"; > > + struct kvm_gmem *gmem; > > + struct inode *inode; > > + struct file *file; > > + int fd, err; > > + > > + fd = get_unused_fd_flags(0); > > + if (fd < 0) > > + return fd; > > + > > + gmem = kzalloc(sizeof(*gmem), GFP_KERNEL); > > + if (!gmem) { > > + err = -ENOMEM; > > + goto err_fd; > > + } > > + > > + /* > > + * Use the so called "secure" variant, which creates a unique inode > > + * instead of reusing a single inode. Each guest_memfd instance needs > > + * its own inode to track the size, flags, etc. > > + */ > > + file = anon_inode_getfile_secure(anon_name, &kvm_gmem_fops, gmem, > > + O_RDWR, NULL); > > + if (IS_ERR(file)) { > > + err = PTR_ERR(file); > > + goto err_gmem; > > + } > > + > > + file->f_flags |= O_LARGEFILE; > > + > > + inode = file->f_inode; > > + WARN_ON(file->f_mapping != inode->i_mapping); > > Just curious, why should we check the mapping fields which is garanteed in > other subsystem? Mostly to document the behavior. The vast majority of folks that read this code will be KVM developers, not file systems developers, and will likely have no clue about the relationship between f_mapping and i_mapping. And in the extremely unlikely scenario that anon_inode_getfile_secure() no longer sets f_mapping, a WARN detects the issue whereas a comment does not. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel