All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, jarkko@kernel.org, kai.huang@intel.com,
	eblake@redhat.com, Yang Zhong <yang.zhong@intel.com>
Subject: Re: [PATCH v4 22/33] hostmem-epc: Add the reset interface for EPC backend reset
Date: Fri, 10 Sep 2021 17:34:29 +0000	[thread overview]
Message-ID: <YTuXJUjR8noe34h6@google.com> (raw)
In-Reply-To: <b940de84-7eac-59de-7b15-15060c31de52@redhat.com>

On Fri, Sep 10, 2021, Paolo Bonzini wrote:
> On 10/09/21 17:34, Sean Christopherson wrote:
> > > Yang explained to me (offlist) that this is needed because Windows fails to
> > > reboot without it.  We would need a way to ask Linux to reinitialize the
> > > vEPC, that doesn't involve munmap/mmap; this could be for example
> > > fallocate(FALLOC_FL_ZERO_RANGE).
> > > 
> > > What do you all think?
> > 
> > Mechanically, FALLOC_FL_ZERO_RANGE could work, but it's definitely a stretch of
> > the semantics as the underlying memory would not actually be zeroed.
> 
> The contents are not visible to anyone, so they might well be zero
> (not entirely serious, but also not entirely unserious).

Yeah, it wouldn't be a sticking point, just odd.

> > The only other option that comes to mind is a dedicated ioctl().
> 
> If it is not too restrictive to do it for the whole mapping at once,
> that would be fine.

Oooh, rats.  That reminds me of a complication.  If QEMU creates multiple EPC
sections, e.g. for a vNUMA setup, resetting each section individually will fail
if the guest did an unclean RESET and a given enclaves has EPC pages from multiple
sections.  E.g. an SECS in vEPC[X] can have children in vEPC[0..N-1], and all
those children need to be removed before the SECS can be removed.  Yay SGX!

> If it makes sense to do it for a range, however,
> the effort of defining a ioctl() API is probably not worth it when
> fallocate() is available.
> 
> Either way, I suppose it would be just something like
> 
> 	/* for fallocate; otherwise just use xa_for_each */
> 	size = min_t(unsigned long, size, -start);
> 	end = (start + size - 1) >> PAGE_SHIFT;
> 	start >>= PAGE_SHIFT;
> 
> 	/*
> 	 * Removing in two passes lets us remove SECS pages as well,
> 	 * since they can only be EREMOVE'd after all their child pages.
> 	 * An EREMOVE failure on the second pass means that the SECS
> 	 * page still has children on another instance.  Since it is
> 	 * still in the xarray, bury our head in the sand and ignore
> 	 * it; sgx_vepc_release() will deal with it.
> 	 */
> 	LIST_HEAD(secs_pages);
>         xa_for_each_range(&vepc->page_array, index, entry, start, end) {
>                 if (!sgx_vepc_free_page(entry))
>                         list_add_tail(&epc_page->list, &secs_pages);
>         }
> 
>         list_for_each_entry_safe(epc_page, tmp, &secs_pages, list) {
> 		list_del(&epc_page->list);
>                 sgx_vepc_free_page(epc_page);
>         }
> So another advantage of the ioctl would be e.g. being able to return the
> number of successfully EREMOVEd pages.  But since QEMU would not do
> anything with the return value and _also_ bury its head in the sand,
> that would only be useful if you guys have other uses in mind.

There are two options: 1) QEMU has to handle "failure", or 2) the kernel provides
an ioctl() that takes multiple vEPC fds and handles the SECS dependencies.  #1 is
probably the least awful option.  For #2, in addition to the kernel having to deal
with multiple fds, it would also need a second list_head object in each page so
that it could track which pages failed to be removed.  Using the existing list_head
would work for now, but it won't work if/when an EPC cgroup is added.

Note, for #1, QEMU would have to potentially do three passes.

  1. Remove child pages for a given vEPC.
  2. Remove SECS for a given vEPC that were pinned by children in the same vEPC.
  3. Remove SECS for all vEPC that were pinned by children in different vEPC.


  reply	other threads:[~2021-09-10 17:35 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 11:21 [PATCH v4 00/33] Qemu SGX virtualization Yang Zhong
2021-07-19 11:21 ` [PATCH v4 01/33] memory: Add RAM_PROTECTED flag to skip IOMMU mappings Yang Zhong
2021-07-19 11:21 ` [PATCH v4 02/33] hostmem: Add hostmem-epc as a backend for SGX EPC Yang Zhong
2021-07-19 11:21 ` [PATCH v4 03/33] qom: Add memory-backend-epc ObjectOptions support Yang Zhong
2021-07-19 11:21 ` [PATCH v4 04/33] i386: Add 'sgx-epc' device to expose EPC sections to guest Yang Zhong
2021-09-14  6:36   ` Philippe Mathieu-Daudé
2021-09-16  1:29     ` Yang Zhong
2021-07-19 11:21 ` [PATCH v4 05/33] vl: Add sgx compound properties to expose SGX " Yang Zhong
2021-07-19 11:21 ` [PATCH v4 06/33] i386: Add primary SGX CPUID and MSR defines Yang Zhong
2021-07-19 11:21 ` [PATCH v4 07/33] i386: Add SGX CPUID leaf FEAT_SGX_12_0_EAX Yang Zhong
2021-07-19 11:21 ` [PATCH v4 08/33] i386: Add SGX CPUID leaf FEAT_SGX_12_0_EBX Yang Zhong
2021-07-19 11:21 ` [PATCH v4 09/33] i386: Add SGX CPUID leaf FEAT_SGX_12_1_EAX Yang Zhong
2021-07-19 11:21 ` [PATCH v4 10/33] i386: Add get/set/migrate support for SGX_LEPUBKEYHASH MSRs Yang Zhong
2021-09-14  6:38   ` Philippe Mathieu-Daudé
2021-09-16  6:08     ` Yang Zhong
2021-09-16  6:35       ` Philippe Mathieu-Daudé
2021-07-19 11:21 ` [PATCH v4 11/33] i386: Add feature control MSR dependency when SGX is enabled Yang Zhong
2021-07-19 11:21 ` [PATCH v4 12/33] i386: Update SGX CPUID info according to hardware/KVM/user input Yang Zhong
2021-07-19 11:21 ` [PATCH v4 13/33] i386: kvm: Add support for exposing PROVISIONKEY to guest Yang Zhong
2021-07-19 11:21 ` [PATCH v4 14/33] i386: Propagate SGX CPUID sub-leafs to KVM Yang Zhong
2021-07-19 11:21 ` [PATCH v4 15/33] Adjust min CPUID level to 0x12 when SGX is enabled Yang Zhong
2021-07-19 11:21 ` [PATCH v4 16/33] hw/i386/fw_cfg: Set SGX bits in feature control fw_cfg accordingly Yang Zhong
2021-07-19 11:21 ` [PATCH v4 17/33] hw/i386/pc: Account for SGX EPC sections when calculating device memory Yang Zhong
2021-07-19 11:21 ` [PATCH v4 18/33] i386/pc: Add e820 entry for SGX EPC section(s) Yang Zhong
2021-07-19 11:21 ` [PATCH v4 19/33] i386: acpi: Add SGX EPC entry to ACPI tables Yang Zhong
2021-07-19 11:21 ` [PATCH v4 20/33] q35: Add support for SGX EPC Yang Zhong
2021-07-19 11:21 ` [PATCH v4 21/33] i440fx: " Yang Zhong
2021-07-19 11:21 ` [PATCH v4 22/33] hostmem-epc: Add the reset interface for EPC backend reset Yang Zhong
2021-09-10 15:10   ` Paolo Bonzini
2021-09-10 15:34     ` Sean Christopherson
2021-09-10 17:09       ` Paolo Bonzini
2021-09-10 17:34         ` Sean Christopherson [this message]
2021-09-10 19:51           ` Paolo Bonzini
2021-09-10 20:21             ` Sean Christopherson
2021-09-10 20:57               ` Paolo Bonzini
2021-09-13 20:17     ` Jarkko Sakkinen
2021-09-13 20:37       ` Sean Christopherson
2021-09-13 21:23         ` Jarkko Sakkinen
2021-07-19 11:21 ` [PATCH v4 23/33] sgx-epc: Add the reset interface for sgx-epc virt device Yang Zhong
2021-09-10 15:13   ` Paolo Bonzini
2021-09-14  6:53   ` Philippe Mathieu-Daudé
2021-09-15 11:33     ` Yang Zhong
2021-07-19 11:21 ` [PATCH v4 24/33] sgx-epc: Avoid bios reset during sgx epc initialization Yang Zhong
2021-07-19 11:21 ` [PATCH v4 25/33] hostmem-epc: Make prealloc consistent with qemu cmdline during reset Yang Zhong
2021-07-19 11:21 ` [PATCH v4 26/33] qmp: Add query-sgx command Yang Zhong
2021-07-19 11:21 ` [PATCH v4 27/33] hmp: Add 'info sgx' command Yang Zhong
2021-07-19 11:21 ` [PATCH v4 28/33] i386: Add sgx_get_info() interface Yang Zhong
2021-07-19 11:21 ` [PATCH v4 29/33] bitops: Support 32 and 64 bit mask macro Yang Zhong
2021-07-19 11:21 ` [PATCH v4 30/33] qmp: Add the qmp_query_sgx_capabilities() Yang Zhong
2021-07-19 11:21 ` [PATCH v4 31/33] Kconfig: Add CONFIG_SGX support Yang Zhong
2021-07-19 11:21 ` [PATCH v4 32/33] sgx-epc: Add the fill_device_info() callback support Yang Zhong
2021-07-19 11:21 ` [PATCH v4 33/33] doc: Add the SGX doc Yang Zhong
2021-07-28 15:57 ` [PATCH v4 00/33] Qemu SGX virtualization Paolo Bonzini
2021-07-29 12:27   ` Yang Zhong
2021-09-06 13:13 ` Paolo Bonzini
2021-09-07  2:24   ` Yang Zhong
2021-09-07  9:51   ` Yang Zhong
2021-09-07 13:35     ` Jarkko Sakkinen
2021-09-08  6:00     ` Paolo Bonzini
2021-09-14  6:51 ` Philippe Mathieu-Daudé
2021-09-15 12:24   ` Yang Zhong

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=YTuXJUjR8noe34h6@google.com \
    --to=seanjc@google.com \
    --cc=eblake@redhat.com \
    --cc=jarkko@kernel.org \
    --cc=kai.huang@intel.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.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 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.