From: David Hildenbrand <david@redhat.com>
To: Andy Lutomirski <luto@kernel.org>,
Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm list <kvm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>,
Andrew Morton <akpm@linux-foundation.org>,
Joerg Roedel <jroedel@suse.de>, Andi Kleen <ak@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Tom Lendacky <thomas.lendacky@amd.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Varad Gautam <varad.gautam@suse.com>,
Dario Faggioli <dfaggioli@suse.com>,
the arch/x86 maintainers <x86@kernel.org>,
linux-mm@kvack.org, linux-coco@lists.linux.dev,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Yu Zhang <yu.c.zhang@linux.intel.com>
Subject: Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory
Date: Wed, 1 Sep 2021 09:49:24 +0200 [thread overview]
Message-ID: <db9b12c1-ba10-879c-61fb-9f711eafaf73@redhat.com> (raw)
In-Reply-To: <ccff0e92-ee24-48e3-ab1f-85a253bb787c@www.fastmail.com>
On 01.09.21 06:58, Andy Lutomirski wrote:
> On Tue, Aug 31, 2021, at 12:07 PM, David Hildenbrand wrote:
>> On 28.08.21 00:18, Sean Christopherson wrote:
>>> On Thu, Aug 26, 2021, David Hildenbrand wrote:
>>>> You'll end up with a VMA that corresponds to the whole file in a single
>>>> process only, and that cannot vanish, not even in parts.
>>>
>>> How would userspace tell the kernel to free parts of memory that it doesn't want
>>> assigned to the guest, e.g. to free memory that the guest has converted to
>>> not-private?
>>
>> I'd guess one possibility could be fallocate(FALLOC_FL_PUNCH_HOLE).
>>
>> Questions are: when would it actually be allowed to perform such a
>> destructive operation? Do we have to protect from that? How would KVM
>> protect from user space replacing private pages by shared pages in any
>> of the models we discuss?
>>
>
> What do you mean? If userspace maliciously replaces a shared page by a private page, then the guest crashes.
Assume we have private pages in a fd and fallocate(FALLOC_FL_PUNCH_HOLE)
random pages the guest is still using. If we "only" crash the guest,
everything is fine.
>
> (The actual meaning here is a bit different on SNP-ES vs TDX. In SNP-ES, a given GPA can be shared, private, or nonexistent. A guest accesses it with a special bit set in the guest page tables to indicate whether it expects shared or private, and the CPU will produce an appropriate error if the bit doesn't match the page.
Rings a bell, thanks for reminding me.
In TDX, there is actually an entirely separate shared vs private
address space, and, in theory, a given "GPA" can exist as shared and as
private at once. The full guest n-bit GPA plus the shared/private bit
is logically an N+1 bit address, and it's possible to map all of it at
once, half shared, and half private. In practice, the defined
guest->host APIs don't really support that usage.
Thanks, that explains a lot.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-09-01 7:49 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 0:52 [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory Sean Christopherson
2021-08-24 10:48 ` Yu Zhang
2021-08-26 0:35 ` Sean Christopherson
2021-08-26 13:23 ` Yu Zhang
2021-08-26 10:15 ` David Hildenbrand
2021-08-26 17:05 ` Andy Lutomirski
2021-08-26 21:26 ` David Hildenbrand
2021-08-27 18:24 ` Andy Lutomirski
2021-08-27 22:28 ` Sean Christopherson
2021-08-31 19:12 ` David Hildenbrand
2021-08-31 20:45 ` Sean Christopherson
2021-09-01 7:51 ` David Hildenbrand
2021-08-27 2:31 ` Yu Zhang
2021-08-31 19:08 ` David Hildenbrand
2021-08-31 20:01 ` Andi Kleen
2021-08-31 20:15 ` David Hildenbrand
2021-08-31 20:39 ` Andi Kleen
2021-09-01 3:34 ` Yu Zhang
2021-09-01 4:53 ` Andy Lutomirski
2021-09-01 7:12 ` Tian, Kevin
2021-09-01 10:24 ` Yu Zhang
2021-09-01 16:07 ` Andy Lutomirski
2021-09-01 16:27 ` David Hildenbrand
2021-09-02 8:34 ` Yu Zhang
2021-09-02 8:44 ` David Hildenbrand
2021-09-02 11:02 ` Yu Zhang
2021-09-02 8:19 ` Yu Zhang
2021-09-02 18:41 ` Andy Lutomirski
2021-09-07 1:33 ` Yan Zhao
2021-09-02 9:27 ` Joerg Roedel
2021-09-02 18:41 ` Andy Lutomirski
2021-09-02 18:57 ` Sean Christopherson
2021-09-02 19:07 ` Dave Hansen
2021-09-02 20:42 ` Andy Lutomirski
2021-08-27 22:18 ` Sean Christopherson
2021-08-31 19:07 ` David Hildenbrand
2021-08-31 21:54 ` Sean Christopherson
2021-09-01 8:09 ` David Hildenbrand
2021-09-01 15:54 ` Andy Lutomirski
2021-09-01 16:16 ` David Hildenbrand
2021-09-01 17:09 ` Andy Lutomirski
2021-09-01 16:18 ` James Bottomley
2021-09-01 16:22 ` David Hildenbrand
2021-09-01 16:31 ` James Bottomley
2021-09-01 16:37 ` David Hildenbrand
2021-09-01 16:45 ` James Bottomley
2021-09-01 17:08 ` David Hildenbrand
2021-09-01 17:50 ` Sean Christopherson
2021-09-01 17:53 ` David Hildenbrand
2021-09-01 17:08 ` Andy Lutomirski
2021-09-01 17:13 ` James Bottomley
2021-09-02 10:18 ` Joerg Roedel
2021-09-01 18:24 ` Andy Lutomirski
2021-09-01 19:26 ` Dave Hansen
2021-09-07 15:00 ` Tom Lendacky
2021-09-01 4:58 ` Andy Lutomirski
2021-09-01 7:49 ` David Hildenbrand [this message]
2021-09-02 18:47 ` Kirill A. Shutemov
2021-09-02 20:33 ` Sean Christopherson
2021-09-03 19:14 ` Kirill A. Shutemov
2021-09-03 19:15 ` Andy Lutomirski
2021-09-10 17:18 ` Kirill A. Shutemov
2021-09-15 19:58 ` Chao Peng
2021-09-15 13:51 ` David Hildenbrand
2021-09-15 14:29 ` Kirill A. Shutemov
2021-09-15 14:59 ` David Hildenbrand
2021-09-15 15:35 ` David Hildenbrand
2021-09-15 20:04 ` Kirill A. Shutemov
2021-09-15 14:11 ` Kirill A. Shutemov
2021-09-16 7:36 ` Chao Peng
2021-09-16 9:24 ` Paolo Bonzini
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=db9b12c1-ba10-879c-61fb-9f711eafaf73@redhat.com \
--to=david@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dfaggioli@suse.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=varad.gautam@suse.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
--cc=yu.c.zhang@linux.intel.com \
/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).