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 6C338C4167B for ; Thu, 2 Nov 2023 16:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4A82280003; Thu, 2 Nov 2023 12:28:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFA548D000F; Thu, 2 Nov 2023 12:28:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC20B280003; Thu, 2 Nov 2023 12:28:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9D43A8D000F for ; Thu, 2 Nov 2023 12:28:56 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 67E2340DA9 for ; Thu, 2 Nov 2023 16:28:56 +0000 (UTC) X-FDA: 81413548272.19.F7A9999 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf14.hostedemail.com (Postfix) with ESMTP id 97B6D10000D for ; Thu, 2 Nov 2023 16:28:54 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="h/X+03Zg"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of dmatlack@google.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=dmatlack@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698942534; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=20owt2l3/cxGLzLA2xbevoL+xSQuNASMB596X3+ow7c=; b=0IYUOm3n6PKIJJ3MwTLU54248O5h98HVqQduwPKekgoelVseNR6ss4CscwRSNjwUML3paw W23vySiYGk/SBLG2LzbT45DTlw3olb9SxJ/15HWStJ+Yq7ERbQ2BEvyF9X5fFe1WjRUwT4 SbCIJIXYYR5Z2vNv205cYPCgaYwSmLM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="h/X+03Zg"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of dmatlack@google.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=dmatlack@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698942534; a=rsa-sha256; cv=none; b=Zl9hCvKDVPDyUrG/SOu78Q9q3OxR1N+T18NTRZ0pcAzH7RBA3xR84fJRYYZS7iswcPwOFR GYjyJf/7ltFHtuj/lepDzTwt6RuAhOz267mH8esQPXygGyOCarF7LQjz0LvxHfpWVPUKG/ a86uRQXZ1qEy+AGaz9nVp4agBa9HJC8= Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4083f613272so10102485e9.1 for ; Thu, 02 Nov 2023 09:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698942533; x=1699547333; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=20owt2l3/cxGLzLA2xbevoL+xSQuNASMB596X3+ow7c=; b=h/X+03Zg5Kk0PJC7sLGdmxRPir+98en+iRFNoXpJLE9DCoU0r81W5aGduiTZO+rn0G q4Xx8HpQ9ZdHoJXHNpH2fPkRqfV4LhkHa/OjeD4rZwNMxeYS/F350JuEW8amINmx3Qaf x6zy4Va/JSOXjcuzyemPW7T6cPVcknpJETTyWTFinYjVSQXnCRzVjqE9c7UT0RkrstL0 vVibxot86KaQteSxGOMbgCnj3ad3rTMyvSTPxUCj+rL38GrGJ8/MGAqQ/GZbVtIirGrL NsH5gCI5INw8PdNqnUHYn8ylGOafeqEfB1FPVjdbeGIlw4BKcuu3D3sMXJ8DJcU15B30 UD8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698942533; x=1699547333; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=20owt2l3/cxGLzLA2xbevoL+xSQuNASMB596X3+ow7c=; b=GL/sOgf9cXa1b6T5LX0PEY3mnqyVmAFmU0F5yE1UNxn6o/FV8bp332WeVb44kbcqGJ ov26xBZYjcExj/jviAq4UkeYiUwuOqZpZCLjZm4J5rxNtgP5dx1kdZKn1mQ0C7nxCktH AYH4eSlS7wPaIexMGvJfVPBjxv7nuq4ri7okxnafBeN1dFu2I1vVJQa1chxwJ0RJJm52 dBav2b7DYUonRbAUZGmoiV/px+KmnucFfkpTW1zPN5imuzIm50ek7Oem2dyZcK8z25w/ +9tknSYKvtWpBsURapugXzjCsu2T9oTn1XeNt8XYNkKPTFj/YsxbmUzyfi6VfDJZIfIW VPTA== X-Gm-Message-State: AOJu0Yw/M8KkFpvquFRSw2jl1oxho4ijt0ikdUwtdfcLMiIB0fje7w1/ ESi+JkEQCBKCYLO0/VxBU0+xagNVmIHxqa/Dm6aokw== X-Google-Smtp-Source: AGHT+IGzC+UPQWsYSxEKly7WToGYHThIxdsAXI0NVkPIoloyom3O4LGBjzNagfuu2dI4j91jKOVPOWF7c1N4gZ20sPc= X-Received: by 2002:a5d:4b51:0:b0:32d:8e54:29f6 with SMTP id w17-20020a5d4b51000000b0032d8e5429f6mr14415276wrs.47.1698942532901; Thu, 02 Nov 2023 09:28:52 -0700 (PDT) MIME-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-17-seanjc@google.com> <6642c379-1023-4716-904f-4bbf076744c2@redhat.com> In-Reply-To: From: David Matlack Date: Thu, 2 Nov 2023 09:28:23 -0700 Message-ID: Subject: Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory To: Sean Christopherson 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 , Yu Zhang , Isaku Yamahata , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , 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="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 97B6D10000D X-Stat-Signature: 5ass4nqwjkbo1dx6jrbrp8hm6aihasox X-Rspam-User: X-HE-Tag: 1698942534-591375 X-HE-Meta: U2FsdGVkX1+4sJD57Sj/MeHzdkcmWxUmDmhvMh97Lhlg30qzmynSXopVQggA+WXMm8WVo77dLhR4wfr4bZPf0IV61IaghJS7hESZKhmPZRa8YA3O1x8zfJP0ySHiVp3OePybLl9AuMhs3/RXSd8CSHvjTMZmwGFP1HOB3Jw9r8hki8bsmdaAfAsaGty1F5m0xlB2DijgFgV0mDo+BMzmmWF3T3ur7C7+6ll6AicBiovHTTOEZZSQN1g51XPVekZcuiK5l7HV4aRogflV2CYYHy/ilON4evd3mJ+LOB8Pp6nVy8XAa9vWgdlnTY0cac/sAUaluLlNSrFDL4+a50MjiFPJGoIAzengo/U18xXpiNG1YnSfo2ntXbh9+SEKY03/kZ9sjGc0WCIFZ0gnFKkrTiZqm8o0gp5CZhp31Fsh79niS6lc/E3duzQFqce0n5/2I7ZusFkHp66tZovGpW7n2n5x9Anh+hia0Ic+OHeYb4RWU39/DE3h0dV/eQsCqtPDcmuglExaOZ+btnCu6EP0jQV2UGomN8yFBr/CdVwh3vEk3q2HajYSS2MmWXKrbs9XkouWTrnXT10GJOl5Iz2Y27vZs+LtrGl59m9wLxNZziEAPibrUBlGhtCo5yFnQ51dsiol0+xcQM6x7Bhkj7PCmSj4a0mTDCwdT9/bxeC/nXtK7TNUW060M5IvXC/8aUqpWxc0+XrdmnYn90xWoSUJvpHrV5CSgdul6nCvvxIsZuuNLXPIPY1J8AmY7Dql3C2LqFP9k9N8/13sa+h7gSHYKzwIiaTETnKazZqtp49ylcvzPewuP+jGPvZEzoFSNxiNjj8dQE1xopFVadYdiGTuk7BRiQ4IcSKjA5n4+0P7CRSQb/GzxyV2FOS65HDGCP5z5WVpcu5D8TsDXh4uGVYMAkN0rzfn3AQZlDpzN7KVV8Q7yK0XcL/cTlqSx8J7mM759ApeObgY7GIOIvDUPwX 99R6XBIF VT6JbDZn7j7AlagQwfQoQEUfxAQeWyQINSQZZNwbkRW/rzXSvQ75IP4xNgMe7NYmlKL4lzHJvNdGOSRk7DtJDuoPA86QOY2kCPIk4hskvIHBab/zqhDRvoaN4sj9GMaC4SWwMB6qZVEemrGjrjFSeRt60Dg6WYli32zWySFG3eMwgeWZWvLcm04SAB+8bjdj4mUfpf6xZUgqx7xQXdm1YLGGaW42JXI8GmSXqA804xFtoz6ztRVxHYhSBMcVWbl2E+oggu+bSSJUeOPIdWbrHfeFkYNB5t8EGHzxkHV1jev6A3xWCp4kx6JtYBGz1lTgXkeSDfkxPnotywk64VeDOOqQoJkgR4obUKfJdufRDBGZWA3tUeBQXXymeQQ== 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: On Thu, Nov 2, 2023 at 9:03=E2=80=AFAM Sean Christopherson wrote: > > On Thu, Nov 02, 2023, Paolo Bonzini wrote: > > On 10/31/23 23:39, David Matlack wrote: > > > > > Maybe can you sketch out how you see this proposal being extensib= le to > > > > > using guest_memfd for shared mappings? > > > > For in-place conversions, e.g. pKVM, no additional guest_memfd is n= eeded. What's > > > > missing there is the ability to (safely) mmap() guest_memfd, e.g. K= VM needs to > > > > ensure there are no outstanding references when converting back to = private. > > > > > > > > For TDX/SNP, assuming we don't find a performant and robust way to = do in-place > > > > conversions, a second fd+offset pair would be needed. > > > Is there a way to support non-in-place conversions within a single gu= est_memfd? > > > > For TDX/SNP, you could have a hook from KVM_SET_MEMORY_ATTRIBUTES to gu= est > > memory. The hook would invalidate now-private parts if they have a VMA= , > > causing a SIGSEGV/EFAULT if the host touches them. > > > > It would forbid mappings from multiple gfns to a single offset of the > > guest_memfd, because then the shared vs. private attribute would be tie= d to > > the offset. This should not be a problem; for example, in the case of = SNP, > > the RMP already requires a single mapping from host physical address to > > guest physical address. > > I don't see how this can work. It's not a M:1 scenario (where M is multi= ple gfns), > it's a 1:N scenario (wheren N is multiple offsets). The *gfn* doesn't ch= ange on > a conversion, what needs to change to do non-in-place conversion is the p= fn, which > is effectively the guest_memfd+offset pair. > > So yes, we *could* support non-in-place conversions within a single guest= _memfd, > but it would require a second offset, Why can't KVM free the existing page at guest_memfd+offset and allocate a new one when doing non-in-place conversions? > at which point it makes sense to add a > second file descriptor as well. Userspace could still use a single guest= _memfd > instance, i.e. pass in the same file descriptor but different offsets.