[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest
From: |
Andy Lutomirski |
Subject: |
Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory |
Date: |
Fri, 01 Apr 2022 12:56:50 -0700 |
User-agent: |
Cyrus-JMAP/3.7.0-alpha0-382-g88b93171a9-fm-20220330.001-g88b93171 |
On Fri, Apr 1, 2022, at 7:59 AM, Quentin Perret wrote:
> On Thursday 31 Mar 2022 at 09:04:56 (-0700), Andy Lutomirski wrote:
> To answer your original question about memory 'conversion', the key
> thing is that the pKVM hypervisor controls the stage-2 page-tables for
> everyone in the system, all guests as well as the host. As such, a page
> 'conversion' is nothing more than a permission change in the relevant
> page-tables.
>
So I can see two different ways to approach this.
One is that you split the whole address space in half and, just like SEV and
TDX, allocate one bit to indicate the shared/private status of a page. This
makes it work a lot like SEV and TDX.
The other is to have shared and private pages be distinguished only by their
hypercall history and the (protected) page tables. This saves some address
space and some page table allocations, but it opens some cans of worms too. In
particular, the guest and the hypervisor need to coordinate, in a way that the
guest can trust, to ensure that the guest's idea of which pages are private
match the host's. This model seems a bit harder to support nicely with the
private memory fd model, but not necessarily impossible.
Also, what are you trying to accomplish by having the host userspace mmap
private pages? Is the idea that multiple guest could share the same page until
such time as one of them tries to write to it? That would be kind of like
having a third kind of memory that's visible to host and guests but is
read-only for everyone. TDX and SEV can't support this at all (a private page
belongs to one guest and one guest only, at least in SEV and in the current TDX
SEAM spec). I imagine that this could be supported with private memory fds
with some care without mmap, though -- the host could still populate the page
with memcpy. Or I suppose a memslot could support using MAP_PRIVATE fds and
have approximately the right semantics.
--Andy
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/04/01
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Sean Christopherson, 2022/04/01
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory,
Andy Lutomirski <=
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/04/04
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Sean Christopherson, 2022/04/04
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Andy Lutomirski, 2022/04/04
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/04/05
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Andy Lutomirski, 2022/04/05
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Sean Christopherson, 2022/04/05
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Andy Lutomirski, 2022/04/06
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/04/06
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Sean Christopherson, 2022/04/05
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/04/06