From: Jarkko Sakkinen <jarkko@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: x86@kernel.org, linux-sgx@vger.kernel.org,
dave.hansen@linux.intel.com, yang.zhong@intel.com
Subject: Re: [PATCH 1/2] x86: sgx_vepc: extract sgx_vepc_remove_page
Date: Tue, 21 Sep 2021 22:44:12 +0300 [thread overview]
Message-ID: <060cfbbaa2c7a1a0643584aa79e6d6f3ab7c8f64.camel@kernel.org> (raw)
In-Reply-To: <20210920125401.2389105-2-pbonzini@redhat.com>
On Mon, 2021-09-20 at 08:54 -0400, Paolo Bonzini wrote:
> For bare-metal SGX on real hardware, the hardware provides guarantees
> SGX state at reboot. For instance, all pages start out uninitialized.
> The vepc driver provides a similar guarantee today for freshly-opened
> vepc instances, but guests such as Windows expect all pages to be in
> uninitialized state on startup, including after every guest reboot.
I would consider replacing
"For bare-metal SGX on real hardware, the hardware provides guarantees
SGX state at reboot. For instance, all pages start out uninitialized."
something like
"On bare-metal SGX, start of a power cycle zeros all of its reserved
memory. This happens after every reboot, but in addition to that
happens after waking up from any of the sleep states."
I can speculate and imagine where this might useful, but no matter how
trivial or complex it is, this patch needs to nail a concrete usage
example. I'd presume you know well the exact changes needed for QEMU, so
from that knowledge it should be easy to write the motivational part.
For instance, point out where it is needed in QEMU and why. I.e. why
you end up in the first place having to re-use vepc buffers (or whatever
they should be called) in QEMU. When that is taken care of, then there is
a red line to eventually ack these patches.
About the motivation.
In Linux we do have a mechanism to take care of this in a guest, for which
motivation was actually first and foremost kexec. It was not done to let VMM to
give a corrupted memory state to a guest.
Even to a Linux guest, since EPC should stil be represented in the state that
matches the hardware. It'd be essentially a corrupted state, even if there was
measures to resist this. Windows guests failing is essentially a side-effect
of an issue, not an issue in the Windows guests.
Since QEMU needs to reinitialize VEPC buffers for guests, it should be as
efficient as we ever can make it. Just fill the gap of understanding why
QEMU needs to do this for guest. This is exactly kind of stuff that you want
have documented in the commit log for future :-)
/Jarkko
next prev parent reply other threads:[~2021-09-21 19:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 12:53 [PATCH 0/2] x86: sgx_vepc: implement ioctl to EREMOVE all pages Paolo Bonzini
2021-09-20 12:54 ` [PATCH 1/2] x86: sgx_vepc: extract sgx_vepc_remove_page Paolo Bonzini
2021-09-21 19:44 ` Jarkko Sakkinen [this message]
2021-09-21 19:46 ` Jarkko Sakkinen
2021-09-23 12:08 ` Paolo Bonzini
2021-09-23 20:33 ` Jarkko Sakkinen
2021-09-20 12:54 ` [PATCH 2/2] x86: sgx_vepc: implement SGX_IOC_VEPC_REMOVE_ALL ioctl Paolo Bonzini
2021-09-20 22:17 ` Kai Huang
2021-09-20 23:09 ` Dave Hansen
2021-09-21 10:29 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2021-09-13 13:11 [RFC/RFT PATCH 0/2] x86: sgx_vepc: implement ioctl to EREMOVE all pages Paolo Bonzini
2021-09-13 13:11 ` [PATCH 1/2] x86: sgx_vepc: extract sgx_vepc_remove_page Paolo Bonzini
2021-09-13 14:05 ` Dave Hansen
2021-09-13 14:24 ` Paolo Bonzini
2021-09-13 14:55 ` Dave Hansen
2021-09-13 15:14 ` Paolo Bonzini
2021-09-13 15:29 ` Dave Hansen
2021-09-13 18:35 ` Paolo Bonzini
2021-09-13 19:25 ` Dave Hansen
2021-09-13 21:16 ` Jarkko Sakkinen
2021-09-13 21:15 ` Jarkko Sakkinen
2021-09-13 21:13 ` Jarkko Sakkinen
2021-09-14 5:36 ` Paolo Bonzini
2021-09-14 16:05 ` Jarkko Sakkinen
2021-09-13 21:12 ` Jarkko Sakkinen
2021-09-13 21:00 ` Jarkko Sakkinen
2021-09-13 20:33 ` Jarkko Sakkinen
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=060cfbbaa2c7a1a0643584aa79e6d6f3ab7c8f64.camel@kernel.org \
--to=jarkko@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=x86@kernel.org \
--cc=yang.zhong@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).