From: Sean Christopherson <seanjc@google.com>
To: Federico Parola <federico.parola@polito.it>
Cc: kvm@vger.kernel.org
Subject: Re: Pre-populate TDP table to avoid page faults at VM boot
Date: Wed, 26 Jul 2023 10:31:50 -0700 [thread overview]
Message-ID: <ZMFYhkSPE6Zbp8Ea@google.com> (raw)
In-Reply-To: <65262e67-7885-971a-896d-ad9c0a760907@polito.it>
On Wed, Jul 26, 2023, Federico Parola wrote:
> Hi everyone,
> is it possible to pre-populate the TDP table (EPT in my case) when
> configuring the VM environment, so that there won't be a page fault / VM
> exit every time the guest tries to access a RAM page for the first time?
No, not yet.
> At the moment I see a lot of page faults when the VM boots, is it possible
> to prevent them to reduce boot time?
You can't currently prevent the page faults, but you can _significantly_ reduce
them by backing guest memory with hugepages. E.g. using 2MiB instead of 4KiB
pages reduces the number of faults by 512x, and 1GiB (HugeTLB only) instead of
2MiB by another 512x.
But the word yet...
KVM needs to add internal APIs to allow userspace to tell to KVM map a particular
GPA in order to support upcoming flavors of confidential VMs[1]. I could have
sworn that I requested that that API be exposed to userspace via a common ioctl(),
e.g. so that userspace can prefault all of guest memory if userspace is so inclined.
Ah, I only made that comment in passing[2].
I'll follow-up in the TDX series to "officially" float the idea of exposing the
helper as an ioctl().
[1] https://lkml.kernel.org/r/6a4c029af70d41b63bcee3d6a1f0c2377f6eb4bd.1690322424.git.isaku.yamahata%40intel.com
[2] https://lore.kernel.org/all/ZGuh1J6AOw5v2R1W@google.com
next prev parent reply other threads:[~2023-07-26 17:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 17:09 Pre-populate TDP table to avoid page faults at VM boot Federico Parola
2023-07-26 17:31 ` Sean Christopherson [this message]
2023-07-26 18:03 ` Federico Parola
2024-02-01 18:11 ` 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=ZMFYhkSPE6Zbp8Ea@google.com \
--to=seanjc@google.com \
--cc=federico.parola@polito.it \
--cc=kvm@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.