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 03A78C5475B for ; Mon, 11 Mar 2024 09:27:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FFD26B007D; Mon, 11 Mar 2024 05:27:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 689B76B007E; Mon, 11 Mar 2024 05:27:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 501C86B0080; Mon, 11 Mar 2024 05:27:13 -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 3B4076B007D for ; Mon, 11 Mar 2024 05:27:13 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 12136120CDA for ; Mon, 11 Mar 2024 09:27:13 +0000 (UTC) X-FDA: 81884229546.11.6899992 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf03.hostedemail.com (Postfix) with ESMTP id 4CA222000D for ; Mon, 11 Mar 2024 09:27:10 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kPZYtif+; spf=pass (imf03.hostedemail.com: domain of tabba@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710149231; 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=8zth3mwh/cKPnkQ6EEGd+vNlUKFtCYJEHeMahy8I+ig=; b=dTn6AAGTg/bfqSjiZ5JTQARefFGGmDbJiaVHu++OcRAvdY/97f91TbO2pRysPcEQ6zMj83 bsle3+/4esxqWAyxtkjCguoDf9dSFr/2KwXRG4JkCp0+xnaiZ67g5TAXNsfYImdb+pV2S0 WsGXf1ZQjy8QlIhWSsqVkFXQXjCrl0g= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kPZYtif+; spf=pass (imf03.hostedemail.com: domain of tabba@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710149231; a=rsa-sha256; cv=none; b=4vUFZQ5hCG27aGyXN5HEIYJKdJLkfsftNPgDDPHfS7Dcjr0oi+5ApmKXQtKyDr6qy3gNJe /nnEZ/qeSgBvRk3wycOR78r9vzEd4Tc3GzjjeBu73IiYsRZ55SUctljIqVeYKJvNHLFaVZ HZFQ2iCVaQ4DbyABsIZaMq6nSxiiryI= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-512bde3d197so3401648e87.0 for ; Mon, 11 Mar 2024 02:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710149229; x=1710754029; 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=8zth3mwh/cKPnkQ6EEGd+vNlUKFtCYJEHeMahy8I+ig=; b=kPZYtif+YjG9oG7AFdPUhZGzHFOfJmirDyvE4rH2e5dAEAOy/Fz7ZBqZAgJhgv9jT5 q0aE1YNIJ3wi4p5gj2DNWny2bDjrv9D22EAXd8vvwuA6QxomC6bkwe8F2RNdZ1SDsdwm 3cZT54Ln9mpuMMTLeNhlmQwy0OYAwuj404jczUUJJor5oSREVgRcnlMjuTd8O4t3yDcp Jza/6G4CPVtxlxrlfYhMK6VvjhVqWrtwk43OIXL/An1PqPB8T7yP5W1bDskxms2N8hch r648XRYiYqJiDpeMFY+kIw88FH6PgG8YewTdglprsY6bMsIGtQlChyM9lKu3kSXi/7a1 eFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710149229; x=1710754029; 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=8zth3mwh/cKPnkQ6EEGd+vNlUKFtCYJEHeMahy8I+ig=; b=R2HnzIf7ZdpBFlW+mypOq6jqN2bp/72Fx2CcCb98d+XkqVF+qnCjz5oNgf8bY5YswU jpWGYQIGHPUXDWrkvVNDW7wT0QOArPo3WPWE+p+vN6nG0TO0c55RvpVObW5tOmRQKHzh ECb+SlcXaIxN5JCdMQyPtV57BG4NIwSeBkZ91RQXRjsM40dEUXeMrmUG9uSauZC0+4HF g6kaSvHh/nTixjx8n1ZeLXS9CaFQ4tGfribvS42eqoxPE9Qn0QdLTEPRuk6DQ8wgb4C4 pJXuLlJBuDFU9KRbF/X5t6tNktp04PYi2Yn3k3wNuVuigJqSQ3UGuEwR5jt2f4XB8Oir hycA== X-Forwarded-Encrypted: i=1; AJvYcCUXknLj/lWHdTKSpLgHuJoNXe51Jqxc0m0jgLVzYrRBXw9m9U5SX6SoOW6ykm0g2IrlJmlCFeULSAE7LGwpiKCVhpA= X-Gm-Message-State: AOJu0YzdfHW8tC83vPfMm8lBleyveIodfzXO/Svlb+a10PftgBkdlZZ1 VnYgGBLQZDzyqdcjjrazFgez2J0cdYABLs8pRWXSTnmXE382n7q4kshiVWV3LCLxnur/Sv19bQn Xukn34vLQFqjC45SiUiTX2iARe6yOOJ66mq/E X-Google-Smtp-Source: AGHT+IFzr2Y971s9TIBNchuVSVv96nsdJjBYbviMit/edW0+/JwqZBjOrNfaM4862cuUg6dthFfgr61zIEYjCiYlE2E= X-Received: by 2002:a05:6512:3baa:b0:513:b102:7d93 with SMTP id g42-20020a0565123baa00b00513b1027d93mr690098lfv.24.1710149229222; Mon, 11 Mar 2024 02:27:09 -0700 (PDT) MIME-Version: 1.0 References: <335E21FA-7F1E-4540-8A70-01A63D8C72FA@amazon.com> In-Reply-To: <335E21FA-7F1E-4540-8A70-01A63D8C72FA@amazon.com> From: Fuad Tabba Date: Mon, 11 Mar 2024 09:26:12 +0000 Message-ID: Subject: Re: Unmapping KVM Guest Memory from Host Kernel To: "Manwaring, Derek" Cc: David Woodhouse , David Matlack , Brendan Jackman , "qperret@google.com" , "jason.cj.chen@intel.com" , "Gowans, James" , "seanjc@google.com" , "akpm@linux-foundation.org" , "Roy, Patrick" , "chao.p.peng@linux.intel.com" , "rppt@kernel.org" , "pbonzini@redhat.com" , "Kalyazin, Nikita" , "lstoakes@gmail.com" , "Liam.Howlett@oracle.com" , "linux-mm@kvack.org" , "qemu-devel@nongnu.org" , "kirill.shutemov@linux.intel.com" , "vbabka@suse.cz" , "mst@redhat.com" , "somlo@cmu.edu" , "Graf (AWS), Alexander" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , "kvmarm@lists.linux.dev" , "kvmarm@lists.cs.columbia.edu" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4CA222000D X-Rspam-User: X-Stat-Signature: htumttpsfsmei9uz78ftaruq5b581utg X-Rspamd-Server: rspam01 X-HE-Tag: 1710149230-294117 X-HE-Meta: U2FsdGVkX1+xeEd9HM7G8135wqNJ+NsA5IJGcVzrItVj94EJgCVVCG1Wyp3xwCu+sVK9GWTykbW8HUCIf1rAs69m7WI6O9bhaosllna62SjvNHx2pTpTHl5VSyU7H50LXT+DFiCw9mlThj7O4Y8Q3YEFCSFWZgAxTNf9/reRbFTa3xoCxeo3X3n0ot9zNV9bKqTyLPwvXdEn93SlRML2s0mUjTPTsbfL7eRUg5EhFWJUfRNoeJRt2aVRgpRZz2aEE5CGKR5vB9bgxe6qQ38LkyT8tc0GnXgbpdwmKLSja3MoWYKXDq81CtipxZHc9B7cmWrL2SNUzcvz5CihfJz51VpCz8ga1wJ7eK6ETzUMTT2jYL5w+nNeBspvladgmhO3mVjsJq/D/9JWHbfqzcdOVB4CaAjyxM5tLKPNdUVKYth4NMD4z/mKlutFWlUuRfxT9ZED1XcwWjidS0X6ZcJ4Le+7yxNPJw55pvJLwWEOHkiw4MzuXW/vhJqkRoJ/7kUbh0ppDwPX9WdOxE3mZWeK/Zx9g2CAlAXsrsriykL6YFPNW/8GNzeBPVjp2fCwGPzm7tzlPuy8H2lRRaRHVKl+TrHDgji5Qp5CZ9tXKil7k61l/I+FH2PYlehApG4afQjOOixzlS8UyH+x72D4MxkZbmwlj7Bz2XD5cx1SDZs4FafOv5qLe7vjOS+YNg2VZAooTJNpUuHS3WVbgygJn5PYJFN69Qs+VZ549ofKJSWPeEJqdssTJn0lRN3/XT6Y5e7bYwWtqWe95uFqOP9kmNjkTIJEFr+5sHnUgqs2RPjGKXesdn5mzs8hLGBw8OX1iPYs1xA9ef7vwm01seaB/r3ucYoQmhZ89S6mCjnu1wC/VRw4AuNBhewTNRwfJnJo3fhPbgBtES327gSmrJF4FeiIolAU3n8WEG2v9s4xsigQj/NtsStRGuBdNqHrTf9FXLRMAsZLxd1qq0qaZkLhKPI 62kJdMmm s4nyZw1EkYoJ0rUj4HhXp1aay/S3F5odHtyGr X-Bogosity: Ham, tests=bogofilter, spamicity=0.162225, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, On Fri, Mar 8, 2024 at 9:05=E2=80=AFPM Manwaring, Derek wrote: > > On 2024-03-08 at 10:46-0700, David Woodhouse wrote: > > On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote: > > > I think what James is looking for (and what we are also interested > > > in), is _eliminating_ the ability to access guest memory from the > > > direct map entirely. And in general, eliminate the ability to access > > > guest memory in as many ways as possible. > > > > Well, pKVM does that... > > Yes we've been looking at pKVM and it accomplishes a lot of what we're tr= ying > to do. Our initial inclination is that we want to stick with VHE for the = lower > overhead. We also want flexibility across server parts, so we would need = to > get pKVM working on Intel & AMD if we went this route. > > Certainly there are advantages of pKVM on the perf side like the in-place > memory sharing rather than copying as well as on the security side by sim= ply > reducing the TCB. I'd be interested to hear others' thoughts on pKVM vs > memfd_secret or general ASI. The work we've done for pKVM is still an RFC [*], but there is nothing in it that limits it to nVHE (at least not intentionally). It should work with VHE and hVHE as well. On respinning the patch series [*], we plan on adding support for normal VMs to use guest_memfd() as well in arm64, mainly for testing, and to make it easier for others to base their work on it. Cheers, /fuad [*] https://lore.kernel.org/all/20240222161047.402609-1-tabba@google.com > > Derek >