On Tue, 10 Oct 2023 19:01:25 -0500, Sean Christopherson
<seanjc@xxxxxxxxxx> wrote:
On Tue, Oct 10, 2023, Haitao Huang wrote:
On Mon, 09 Oct 2023 21:23:12 -0500, Huang, Kai <kai.huang@xxxxxxxxx>
wrote:
> On Mon, 2023-10-09 at 20:42 -0500, Haitao Huang wrote:
> > Hi Sean
> >
> > On Mon, 09 Oct 2023 19:23:04 -0500, Sean Christopherson
> > <seanjc@xxxxxxxxxx> wrote:
> > > I can see userspace wanting to explicitly terminate the VM
instead of
> > > "silently"
> > > the VM's enclaves, but that seems like it should be a knob in the
> > > virtual EPC
> > > code.
> >
> > If my understanding above is correct and understanding your
statement
> > above correctly, then don't see we really need separate knob for
vEPC
> > code. Reaching a cgroup limit by a running guest (assuming dynamic
> > allocation implemented) should not translate automatically killing
> > the VM.
> > Instead, it's user space job to work with guest to handle allocation
> > failure. Guest could page and kill enclaves.
> >
>
> IIUC Sean was talking about changing misc.max _after_ you launch SGX
VMs:
>
> 1) misc.max = 100M
> 2) Launch VMs with total virtual EPC size = 100M <- success
> 3) misc.max = 50M
>
> 3) will also succeed, but nothing will happen, the VMs will be still
> holding 100M EPC.
>
> You need to somehow track virtual EPC and kill VM instead.
>
> (or somehow fail to do 3) if it is also an acceptable option.)
>
Thanks for explaining it.
There is an error code to return from max_write. I can add that too to
the
callback definition and fail it when it can't be enforced for any
reason.
Would like some community feedback if this is acceptable though.
That likely isn't acceptable. E.g. create a cgroup with both a host
enclave and
virtual EPC, set the hard limit to 100MiB. Virtual EPC consumes 50MiB,
and the
host enclave consumes 50MiB. Userspace lowers the limit to 49MiB. The
cgroup
code would reclaim all of the enclave's reclaimable EPC, and then kill
the enclave
because it's still over the limit. And then fail the max_write because
the cgroup
is *still* over the limit. So in addition to burning a lot of cycles,
from
userspace's perspective its enclave was killed for no reason, as the new
limit
wasn't actually set.
I was thinking before reclaiming enclave pages, if we know the untracked
vepc pages (current-tracked) is larger than limit, we just return error
without enforcing the limit. That way user also knows something is wrong.
But I get that we want to be able to kill VMs to enforce the newer lower
limit. I assume we can't optimize efficiency/priority of killing: enclave
pages will be reclaimed first no matter what just because they are
reclaimable; no good rules to choose victim between enclave and VMs in
your example so enclaves could be killed still before VMs.
I think to solve it ultimately, we need be able to adjust 'capacity' of
VMs
not to just kill them, which is basically the same as dynamic allocation
support for VMs (being able to increase/decrease epc size when it is
running). For now, we only have static allocation so max can't be
enforced
once it is launched.
No, reclaiming virtual EPC is not a requirement. VMM EPC
oversubscription is
insanely complex, and I highly doubt any users actually want to
oversubcribe VMs.
There are use cases for cgroups beyond oversubscribing/swapping, e.g.
privileged
userspace may set limits on a container to ensure the container doesn't
*accidentally*
consume more EPC than it was allotted, e.g. due to a configuration bug
that created
a VM with more EPC than it was supposed to have.
My comments on virtual EPC vs. cgroups is much more about having sane,
well-defined
behavior, not about saying the kernel actually needs to support
oversubscribing EPC
for KVM guests.
So here are the steps I see now, let me know if this is aligned with your
thinking or I'm off track.
0) when all left are enclave VA, SECS pages and VEPC in a cgroup, the OOM
kill process starts.
1) The cgroup identifies a victim vepc for OOM kill(this could be before
or after enclaves being killed), sets a new flag VEPC_NO_MEMORY in the
vepc.
2) call sgx_vepc_remove_all(), ignore failure counts returned. This will
perform best effort to eremove all normal pages used by the vepc.
3) Guest may trigger fault again, return SIGBUS in sgx_vepc_fault when
VEPC_NO_MEMORY is set. Do the same for mmap.
4) That would eventually cause sgx_vepc_release() before VM dies or killed
by user space, which does the final cleanup.
Q: should we reset VEPC_NO_MEMORY flag if #4 never happens and cgroup
usage is below limit? I suppose we can do it, but not sure it is sane
because VM would try to load as much pages as configured originally.
I'm still thinking about using one unreclaimable list, justification is
simplicity and lack of rules to select items from separate lists, but may
change my mind if I found it's inconvenient.
Not sure how age/youngness can be accounted for guest pages though Kai
indicated we don't need that for first version. So I assume we can deal
with it later and add separate list for vEPC if needed
for that reason.
Thanks a lot for your input.
Haitao
