From: Eric van Tassell <evantass@amd.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: eric van tassell <Eric.VanTassell@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"Singh, Brijesh" <Brijesh.Singh@amd.com>,
"Grimm, Jon" <Jon.Grimm@amd.com>,
kvm@vger.kernel.org, bp@alien8.de, hpa@zytor.com,
mingo@redhat.com, jmattson@google.com, joro@8bytes.org,
pbonzini@redhat.com, tglx@linutronix.de, vkuznets@redhat.com,
wanpengli@tencent.com, x86@kernel.org
Subject: Re: [Patch 2/4] KVM:SVM: Introduce set_spte_notify support
Date: Thu, 20 Aug 2020 12:05:00 -0500 [thread overview]
Message-ID: <fdead941-6dec-ec97-5eea-9461b7e5d89a@amd.com> (raw)
In-Reply-To: <20200819160557.GD20459@linux.intel.com>
On 8/19/20 11:05 AM, Sean Christopherson wrote:
> On Wed, Aug 19, 2020 at 11:03:48AM -0500, Eric van Tassell wrote:
>>
>>
>> On 8/3/20 11:27 AM, Sean Christopherson wrote:
>>> On Sun, Aug 02, 2020 at 03:53:54PM -0500, Eric van Tassell wrote:
>>>>
>>>> On 7/31/20 3:25 PM, Sean Christopherson wrote:
>>>>> On Fri, Jul 24, 2020 at 06:54:46PM -0500, eric van tassell wrote:
>>>>>> Improve SEV guest startup time from O(n) to a constant by deferring
>>>>>> guest page pinning until the pages are used to satisfy nested page faults.
>>>>>>
>>>>>> Implement the code to do the pinning (sev_get_page) and the notifier
>>>>>> sev_set_spte_notify().
>>>>>>
>>>>>> Track the pinned pages with xarray so they can be released during guest
>>>>>> termination.
>>>>>
>>>>> I like that SEV is trying to be a better citizen, but this is trading one
>>>>> hack for another.
>>>>>
>>>>> - KVM goes through a lot of effort to ensure page faults don't need to
>>>>> allocate memory, and this throws all that effort out the window.
>>>>>
>>>> can you elaborate on that?
>>>
>>> mmu_topup_memory_caches() is called from the page fault handlers before
>>> acquiring mmu_lock to pre-allocate shadow pages, PTE list descriptors, GFN
>>> arrays, etc... that may be needed to handle the page fault. This allows
>>> using standard GFP flags for the allocation and obviates the need for error
>>> handling in the consumers.
>>>
>>
>> I see what you meant. The issue that causes us to use this approach is that
>> we need to be able to unpin the pages when the VM exits.
>
> Yes, but using a software available flag in the SPTE to track pinned pages
> should be very doable.
>
The issue, as I understand it, is that when spte(s) get zapped/unzapped,
the flags are lost so we'd have to have some mechanism to, before
zapping, cache the pfn <-> spte mapping
next prev parent reply other threads:[~2020-08-20 17:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 23:54 [Patch 0/4] Defer page pinning for SEV guests until guest pages touched eric van tassell
2020-07-24 23:54 ` [Patch 1/4] KVM:MMU: Introduce the set_spte_notify() callback eric van tassell
2020-07-24 23:54 ` [Patch 2/4] KVM:SVM: Introduce set_spte_notify support eric van tassell
2020-07-31 20:25 ` Sean Christopherson
2020-08-02 20:53 ` Eric van Tassell
2020-08-03 16:27 ` Sean Christopherson
2020-08-19 16:03 ` Eric van Tassell
2020-08-19 16:05 ` Sean Christopherson
2020-08-20 17:05 ` Eric van Tassell [this message]
2020-08-20 23:59 ` Sean Christopherson
2020-08-21 0:36 ` Eric van Tassell
2020-08-21 18:16 ` Eric van Tassell
2020-07-24 23:54 ` [Patch 3/4] KVM:SVM: Pin sev_launch_update_data() pages via sev_get_page() eric van tassell
2020-07-31 20:40 ` Sean Christopherson
2020-08-02 23:55 ` Eric van Tassell
2020-08-19 16:20 ` Eric van Tassell
2020-07-24 23:54 ` [Patch 4/4] KVM:SVM: Remove struct enc_region and associated pinned page tracking eric van tassell
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=fdead941-6dec-ec97-5eea-9461b7e5d89a@amd.com \
--to=evantass@amd.com \
--cc=Brijesh.Singh@amd.com \
--cc=Eric.VanTassell@amd.com \
--cc=Jon.Grimm@amd.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/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).