On Thu, 2022-04-28 at 16:49 -0700, Reinette Chatre wrote: > > > > I also looked a little deeper at this transient failure problem. The > > ELDU documentation also mentions a possible error code of: > > > > SGX_EPC_PAGE_CONFLICT > > > > It *looks* like there can be conflicts on the SECS page as well as the > > EPC page being explicitly accessed. Is that a possible problem here? > > I went down this path myself. SGX_EPC_PAGE_CONFLICT is an error code > supported by newer ELDUC - the ELDU used in current code would indeed > #GP in this case. The SDM text describing ELDUC as "This leaf function > behaves like ELDU but with improved conflict handling for oversubscription" > really does seem relevant to the test that triggers this issue. This new error code and the new leaf functions with "C" postfix (ELDUC, etc) are introduced to support VMM oversubscription of EPC. VMM oversubscription of EPC runs independently with guest so theoretically when VMM is performing some operation on EPC in one CPU, guest running in another CPU can touch the EPC simultaneously. The new "C" variants are supposed to be used by VMM when it supports VMM oversubscription of EPC, so that the VMM can a ENCLS instruction error code, rather than a #GP when this case happens. At guest side, when ENCLS conflicting happens, VMM will get a VM-exit so it can be handed by VMM, i.e. by letting the guest to run the same ENCLS again. For now the SGX driver doesn't need to use the "C" variant, nor should it expect the new SGX_EPC_PAGE_CONFLICT error code, because the driver already needs to serialize those ENCLS leaf functions which can not run concurrently. I assume this should apply to SGX2 support too. -- Thanks, -Kai
