Messages in this thread | | | Date | Wed, 1 Sep 2021 16:47:32 +0000 | From | Sean Christopherson <> | Subject | Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in restore_fpregs_from_user() |
| |
On Wed, Sep 01, 2021, Thomas Gleixner wrote: > On Wed, Sep 01 2021 at 14:00, Thomas Gleixner wrote: > > > > commit b2f9d678e28c ("x86/mce: Check for faults tagged in > > EXTABLE_CLASS_FAULT exception table entries") made use of this in MCE to > > allow in kernel recovery. The only thing it uses is checking the > > exception handler type. > > > > Bah. I'll fix that up to make that less obscure. > > > > The remaining two use cases (SGX and FPU) make use of the stored trap > > number. > > Though while for the FPU use case we really want to handle the #MC case, > it's not clear to me whether this is actually correct for SGX. > > Jarkko, Sean, Dave?
Are you asking about #MC specifically, or about SGX consuming the trap number in general?
For #MC, it's probably a moot point because #MC on ENCLS is not recoverable for current hardware. If #MC somehow occurs on ENCLS and doesn't kill the platform, "handling" the #MC in SGX is probably wrong. Note, Tony is working on a series to support recoverable #MC on SGX stuff on future hardware[*], but I'm not sure that's relevant to this discussion.
As for SGX consuming the trap number in general, it's correct. For non-KVM usage, it's nice to have but not strictly necessary. Any fault except #PF on ENCLS is guaranteed to be a kernel or hardware bug; SGX uses the trap number to WARN on a !#PF exception, e.g. on #GP or #UD. Not having the trap number would mean losing those sanity checks, which have been useful in the past.
For virtualizing SGX, KVM needs the trap number so that it can inject the correct exception into the guest, e.g. if the guest violates the ENCLS concurrency rules it should get a #GP, whereas a EPCM violation should #PF.
[*] https://lore.kernel.org/lkml/20210827195543.1667168-1-tony.luck@intel.com
| |