From: Alexander Graf <graf@amazon.com>
To: Sean Christopherson <seanjc@google.com>
Cc: "Alex Williamson" <alex.williamson@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
kvm@vger.kernel.org, "Xiao Guangrong" <guangrong.xiao@gmail.com>,
"Chandrasekaran, Siddharth" <sidcha@amazon.de>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH v2 11/27] KVM: x86/mmu: Zap only the relevant pages when removing a memslot
Date: Thu, 20 Oct 2022 23:06:50 +0200 [thread overview]
Message-ID: <cdaf34bc-b2ab-1a9d-22d0-3d9dc3364bf2@amazon.com> (raw)
In-Reply-To: <Y1GxnGo3A8UF3iTt@google.com>
On 20.10.22 22:37, Sean Christopherson wrote:
> On Thu, Oct 20, 2022, Alexander Graf wrote:
>> On 26.06.20 19:32, Sean Christopherson wrote:
>>> /cast <thread necromancy>
>>>
>>> On Tue, Aug 20, 2019 at 01:03:19PM -0700, Sean Christopherson wrote:
>> [...]
>>
>>> I don't think any of this explains the pass-through GPU issue. But, we
>>> have a few use cases where zapping the entire MMU is undesirable, so I'm
>>> going to retry upstreaming this patch as with per-VM opt-in. I wanted to
>>> set the record straight for posterity before doing so.
>> Hey Sean,
>>
>> Did you ever get around to upstream or rework the zap optimization? The way
>> I read current upstream, a memslot change still always wipes all SPTEs, not
>> only the ones that were changed.
> Nope, I've more or less given up hope on zapping only the deleted/moved memslot.
> TDX (and SNP?) will preserve SPTEs for guest private memory, but they're very
> much a special case.
>
> Do you have use case and/or issue that doesn't play nice with the "zap all" behavior?
Yeah, we're looking at adding support for the Hyper-V VSM extensions
which Windows uses to implement Credential Guard. With that, the guest
gets access to hypercalls that allow it to set reduced permissions for
arbitrary gfns. To ensure that user space has full visibility into those
for live migration, memory slots to model access would be a great fit.
But it means we'd do ~100k memslot modifications on boot.
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
next prev parent reply other threads:[~2022-10-20 21:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-05 20:54 [PATCH v2 00/27] KVM: x86/mmu: Remove fast invalidate mechanism Sean Christopherson
2019-02-05 20:54 ` [PATCH v2 01/27] KVM: Call kvm_arch_memslots_updated() before updating memslots Sean Christopherson
2019-02-06 9:12 ` Cornelia Huck
2019-02-12 12:36 ` [PATCH v2 00/27] KVM: x86/mmu: Remove fast invalidate mechanism Paolo Bonzini
[not found] ` <20190205210137.1377-11-sean.j.christopherson@intel.com>
2019-08-13 16:04 ` [PATCH v2 11/27] KVM: x86/mmu: Zap only the relevant pages when removing a memslot Alex Williamson
2019-08-13 17:04 ` Sean Christopherson
2019-08-13 17:57 ` Alex Williamson
2019-08-13 19:33 ` Alex Williamson
2019-08-13 20:19 ` Sean Christopherson
2019-08-13 20:37 ` Paolo Bonzini
2019-08-13 21:14 ` Alex Williamson
2019-08-13 21:15 ` Paolo Bonzini
2019-08-13 22:10 ` Alex Williamson
2019-08-15 14:46 ` Sean Christopherson
2019-08-15 15:23 ` Alex Williamson
2019-08-15 16:00 ` Sean Christopherson
2019-08-15 18:16 ` Alex Williamson
2019-08-15 19:25 ` Sean Christopherson
2019-08-15 20:11 ` Alex Williamson
2019-08-19 16:03 ` Paolo Bonzini
2019-08-20 20:03 ` Sean Christopherson
2019-08-20 20:42 ` Alex Williamson
2019-08-20 21:02 ` Sean Christopherson
2019-08-21 19:08 ` Alex Williamson
2019-08-21 19:35 ` Alex Williamson
2019-08-21 20:30 ` Sean Christopherson
2019-08-23 2:25 ` Sean Christopherson
2019-08-23 22:05 ` Alex Williamson
2019-08-21 20:10 ` Sean Christopherson
2019-08-26 7:36 ` Tian, Kevin
2019-08-26 14:56 ` Sean Christopherson
2020-06-26 17:32 ` Sean Christopherson
2022-10-20 18:31 ` Alexander Graf
2022-10-20 20:37 ` Sean Christopherson
2022-10-20 21:06 ` Alexander Graf [this message]
2022-10-21 19:40 ` Sean Christopherson
2022-10-24 6:12 ` Alexander Graf
2022-10-24 15:55 ` Sean Christopherson
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=cdaf34bc-b2ab-1a9d-22d0-3d9dc3364bf2@amazon.com \
--to=graf@amazon.com \
--cc=alex.williamson@redhat.com \
--cc=guangrong.xiao@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=seanjc@google.com \
--cc=sidcha@amazon.de \
/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).