On Mon, 16 Oct 2023 20:34:57 -0500, Huang, Kai <kai.hu...@intel.com> wrote:

On Mon, 2023-10-16 at 19:10 -0500, Haitao Huang wrote:
On Mon, 16 Oct 2023 16:09:52 -0500, Huang, Kai <kai.hu...@intel.com> wrote:

> still need to fix the bug mentioned above here.
> I really think you should just go this simple way:
> When you want to take EPC back from VM, kill the VM.

My only concern is that this is a compromise due to current limitation (no
other sane way to take EPC from VMs). If we define this behavior and it
becomes a contract to user space, then we can't change in future.

Why do we need to "define such behaviour"?

This isn't some kinda of kernel/userspace ABI IMHO, but only kernel internal implementation. Here VM is similar to normal host enclaves. You limit the resource, some host enclaves could be killed. Similarly, VM could also be
killed too.

And supporting VMM EPC oversubscription doesn't mean VM won't be killed. The VM can still be a target to kill after VM's all EPC pages have been swapped out.

On the other hand, my understanding the reason you want this behavior is
to enforce EPC limit at runtime.

No I just thought this is a bug/issue needs to be fixed. If anyone believes
this is not a bug/issue then it's a separate discussion.

AFAIK, before we introducing max_write() callback in this series, no misc controller would possibly enforce the limit when misc.max is reduced. e.g. I don't think CVMs be killed when ASID limit is reduced and the cgroup was full before limit is reduced.

I think EPC pages to VMs could have the same behavior, once they are given to a guest, never taken back by the host. For enclaves on host side, pages are reclaimable, that allows us to enforce in a similar way to memcg.


Reply via email to