Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Yan Zhao <yan.y.zhao@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
	<kexec@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<linux-coco@lists.linux.dev>, <x86@kernel.org>,
	<rick.p.edgecombe@intel.com>, <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH] kexec_core: Accept unaccepted kexec destination addresses
Date: Thu, 24 Oct 2024 08:15:13 +0800	[thread overview]
Message-ID: <ZxmRkUNmx863Po2U@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <87cyjq7rjo.fsf@email.froward.int.ebiederm.org>

On Wed, Oct 23, 2024 at 10:44:11AM -0500, Eric W. Biederman wrote:
> "Kirill A. Shutemov" <kirill@shutemov.name> writes:
> 
> > Waiting minutes to get VM booted to shell is not feasible for most
> > deployments. Lazy is sane default to me.
> 
> Huh?
> 
> Unless my guesses about what is happening are wrong lazy is hiding
> a serious implementation deficiency.  From all hardware I have seen
> taking minutes is absolutely ridiculous.
> 
> Does writing to all of memory at full speed take minutes?  How can such
> a system be functional?
> 
> If you don't actually have to write to the pages and it is just some
> accounting function it is even more ridiculous.
> 
> 
> I had previously thought that accept_memory was the firmware call.
> Now that I see that it is just a wrapper for some hardware specific
> calls I am even more perplexed.
> 
> 
> Quite honestly what this looks like to me is that someone failed to
> enable write-combining or write-back caching when writing to memory
> when initializing the protected memory.  With the result that everything
> is moving dog slow, and people are introducing complexity left and write
> to avoid that bad implementation.
> 
> 
> Can someone please explain to me why this accept_memory stuff has to be
> slow, why it has to take minutes to do it's job.
This kexec patch is a fix to a guest(TD)'s kexce failure.

For a linux guest, the accept_memory() happens before the guest accesses a page.
It will (if the guest is a TD)
(1) trigger the host to allocate the physical page on host to map the accessed
    guest page, which might be slow with wait and sleep involved, depending on
    the memory pressure on host.
(2) initializing the protected page.

Actually most of guest memory are not accessed by guest during the guest life
cycle. accept_memory() may cause the host to commit a never-to-be-used page,
with the host physical page not even being able to get swapped out.

That's why we need a lazy accept, which does not accept_memory() until after a
page is allocated by the kernel (in alloc_page(s)).

> I would much rather spend my time figuring out how to make accept_memory
> run at a reasonable speed than to litter the kernel with more of this
> nonsense.
> 
> Eric

  reply	other threads:[~2024-10-24  0:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-21  3:45 [PATCH] kexec_core: Accept unaccepted kexec destination addresses Yan Zhao
2024-10-21 14:33 ` Eric W. Biederman
2024-10-22  3:12   ` Yan Zhao
2024-10-22 12:06   ` Kirill A. Shutemov
2024-10-23 15:44     ` Eric W. Biederman
2024-10-24  0:15       ` Yan Zhao [this message]
2024-10-24  0:26         ` Yan Zhao
2024-11-26 11:38         ` Baoquan He
2024-11-27 10:01           ` Yan Zhao
2024-11-28 15:19             ` Baoquan He
2024-11-29  5:52               ` Yan Zhao
2024-12-02 14:17                 ` Baoquan He
2024-12-03 10:06                   ` Yan Zhao
2024-12-03 10:30                     ` Baoquan He
2024-12-04  9:19                       ` Yan Zhao
2024-10-25 13:56       ` Kirill A. Shutemov
2024-11-04  8:35         ` Kirill A. Shutemov
2024-11-08 12:29           ` Kirill A. Shutemov

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=ZxmRkUNmx863Po2U@yzhao56-desk.sh.intel.com \
    --to=yan.y.zhao@intel.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rick.p.edgecombe@intel.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