qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Gowans, James" <jgowans@amazon.com>
To: "seanjc@google.com" <seanjc@google.com>,
	"Roy, Patrick" <roypat@amazon.co.uk>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Kalyazin, Nikita" <kalyazin@amazon.co.uk>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"rppt@kernel.org" <rppt@kernel.org>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"somlo@cmu.edu" <somlo@cmu.edu>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"Woodhouse, David" <dwmw@amazon.co.uk>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>, "Graf (AWS),
	Alexander" <graf@amazon.de>,
	"Manwaring, Derek" <derekmn@amazon.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"lstoakes@gmail.com" <lstoakes@gmail.com>,
	"mst@redhat.com" <mst@redhat.com>
Subject: Re: Unmapping KVM Guest Memory from Host Kernel
Date: Mon, 13 May 2024 16:01:22 +0000	[thread overview]
Message-ID: <aaf684b5eb3a3fe9cfbb6205c16f0973c6f8bb07.camel@amazon.com> (raw)
In-Reply-To: <ZkI0SCMARCB9bAfc@google.com>

On Mon, 2024-05-13 at 08:39 -0700, Sean Christopherson wrote:
> > Sean, you mentioned that you envision guest_memfd also supporting non-CoCo VMs.
> > Do you have some thoughts about how to make the above cases work in the
> > guest_memfd context?
> 
> Yes.  The hand-wavy plan is to allow selectively mmap()ing guest_memfd().  There
> is a long thread[*] discussing how exactly we want to do that.  The TL;DR is that
> the basic functionality is also straightforward; the bulk of the discussion is
> around gup(), reclaim, page migration, etc.

I still need to read this long thread, but just a thought on the word
"restricted" here: for MMIO the instruction can be anywhere and
similarly the load/store MMIO data can be anywhere. Does this mean that
for running unmodified non-CoCo VMs with guest_memfd backend that we'll
always need to have the whole of guest memory mmapped?

I guess the idea is that this use case will still be subject to the
normal restriction rules, but for a non-CoCo non-pKVM VM there will be 
no restriction in practice, and userspace will need to mmap everything
always?

It really seems yucky to need to have all of guest RAM mmapped all the
time just for MMIO to work... But I suppose there is no way around that
for Intel x86.

JG

> 
> [*] https://lore.kernel.org/all/ZdfoR3nCEP3HTtm1@casper.infradead.org


  reply	other threads:[~2024-05-13 16:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AQHacXBJeX10YUH0O0SiQBg1zQLaEw==>
2024-03-08 15:50 ` Unmapping KVM Guest Memory from Host Kernel Gowans, James
2024-03-08 16:25   ` Brendan Jackman
2024-03-08 17:35     ` David Matlack
2024-03-08 17:45       ` David Woodhouse
2024-03-08 22:47         ` Sean Christopherson
2024-03-09  2:45       ` Manwaring, Derek
2024-03-18 14:11         ` Brendan Jackman
2024-03-08 23:22   ` Sean Christopherson
2024-03-09 11:14     ` Mike Rapoport
2024-05-13 10:31       ` Patrick Roy
2024-05-13 15:39         ` Sean Christopherson
2024-05-13 16:01           ` Gowans, James [this message]
2024-05-13 17:09             ` Sean Christopherson
2024-05-13 19:43               ` Gowans, James
2024-05-13 20:36                 ` Sean Christopherson
2024-05-13 22:01                   ` Manwaring, Derek
2024-03-14 21:45     ` Manwaring, Derek
2024-03-09  5:01   ` Matthew Wilcox
2024-03-08 21:05 Manwaring, Derek
2024-03-11  9:26 ` Fuad Tabba
2024-03-11  9:29   ` Fuad Tabba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaf684b5eb3a3fe9cfbb6205c16f0973c6f8bb07.camel@amazon.com \
    --to=jgowans@amazon.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=chao.p.peng@linux.intel.com \
    --cc=derekmn@amazon.com \
    --cc=dwmw@amazon.co.uk \
    --cc=graf@amazon.de \
    --cc=kalyazin@amazon.co.uk \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=roypat@amazon.co.uk \
    --cc=rppt@kernel.org \
    --cc=seanjc@google.com \
    --cc=somlo@cmu.edu \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).