On Mon, Mar 28, 2022, Quentin Perret wrote: > Hi Sean, > > Thanks for the reply, this helps a lot. > > On Monday 28 Mar 2022 at 17:13:10 (+0000), Sean Christopherson wrote: > > On Thu, Mar 24, 2022, Quentin Perret wrote: > > > For Protected KVM (and I suspect most other confidential computing > > > solutions), guests have the ability to share some of their pages back > > > with the host kernel using a dedicated hypercall. This is necessary > > > for e.g. virtio communications, so these shared pages need to be mapped > > > back into the VMM's address space. I'm a bit confused about how that > > > would work with the approach proposed here. What is going to be the > > > approach for TDX? > > > > > > It feels like the most 'natural' thing would be to have a KVM exit > > > reason describing which pages have been shared back by the guest, and to > > > then allow the VMM to mmap those specific pages in response in the > > > memfd. Is this something that has been discussed or considered? > > > > The proposed solution is to exit to userspace with a new exit reason, KVM_EXIT_MEMORY_ERROR, > > when the guest makes the hypercall to request conversion[1]. The private fd itself > > will never allow mapping memory into userspace, instead userspace will need to punch > > a hole in the private fd backing store. The absense of a valid mapping in the private > > fd is how KVM detects that a pfn is "shared" (memslots without a private fd are always > > shared)[2]. > > Right. I'm still a bit confused about how the VMM is going to get the > shared page mapped in its page-table. Once it has punched a hole into > the private fd, how is it supposed to access the actual physical page > that the guest shared? The guest doesn't share a _host_ physical page, the guest shares a _guest_ physical page. Until host userspace converts the gfn to shared and thus maps the gfn=>hva via mmap(), the guest is blocked and can't read/write/exec the memory. AFAIK, no architecture allows in-place decryption of guest private memory. s390 allows a page to be "made accessible" to the host for the purposes of swap, and other architectures will have similar behavior for migrating a protected VM, but those scenarios are not sharing the page (and they also make the page inaccessible to the guest). > Is there an assumption somewhere that the VMM should have this page mapped in > via an alias that it can legally access only once it has punched a hole at > the corresponding offset in the private fd or something along those lines? Yes, the VMM must have a completely separate VMA. The VMM doesn't haven't to wait until the conversion to mmap() the shared variant, though obviously it will potentially consume double the memory if the VMM actually populates both the private and shared backing stores. > > The key point is that KVM never decides to convert between shared and private, it's > > always a userspace decision. Like normal memslots, where userspace has full control > > over what gfns are a valid, this gives userspace full control over whether a gfn is > > shared or private at any given time. > > I'm understanding this as 'the VMM is allowed to punch holes in the > private fd whenever it wants'. Is this correct?
