From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5043028E07 for ; Mon, 6 Nov 2023 15:43:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vzsyRpmA" Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CE83118 for ; Mon, 6 Nov 2023 07:43:23 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5a8d9dcdd2bso93832507b3.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=vger.kernel.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=vzsyRpmAxCH/8GChvrGqDn1yvCAI0owjxSc6wm0w6nRGowEL6uQH0k86wM3BowHnWI YO+R/Q2MeQV7zL2YvlMRp+22CKQJHYviHQJiz0i65xCl7cDkcN92Hc+gP14ppMymRD2H aNKuUvrMcOB0Y4b701bftPjfVwD1nBdpNRCXnjvIWg7qEQYr6bnVR10Wr9ZRLz5WKfcL qITuyIHcTB0+pH6vcpcz51cGsP3HxdLI6QiqVZ5anzF+GCPejnwTJ6NV8yQuDbkP8EAc /QZSYZnij1meUOSvTcHCycSqLXFAA8JQQ7ufFnyiSnwYFLNV/kl6P7zkJFOHvY7xbPv8 Os3w== 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=eOmTKJIJZ+56bfNUW0mQR41B6aQmosZURorKkMOWrNnV4dpUiAVWfsRRcuRCJsW5c9 PKvXsfpdDvLc/Rni/tGbaKp6e5oXDZHi7HbbfnZQEfYfjBoXcsP0DvcYgygqJOQ9aN29 lUi+TlGfjCJTtPFDyaosbsUBvTDDEeEdhYsHswNVhtrJD3rpeOM6FCtbbpaB3VwbCDmU 6ISikPtyFfzcX0aSx9yU55V9vVHkp7cCtVCAjN2durjHW+VuMmZg1XxSVlb7tMh+Qwu8 8ZN2Yk02BZVUAxv3aYThCgJIuw1dQdyCjS8O/AyM8vVS1aRYUFTrXjs65vzUi7MJe4Ma 3Yrw== X-Gm-Message-State: AOJu0Yz3p3L7ylBILuASg2s71rq03yMfpSK1yDpIUDrojlIJCud0M8XO mvoeH6TSoY1H/fPdCJltcQV4TlGiuBc= 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: kvm@vger.kernel.org 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.