On Thu, Oct 21, 2021 at 04:57:09PM -0300, Marcelo Tosatti wrote:
quoted
Pretty much everything in noinstr is magical, we just have to think
harder there (and possibly start writing more comments there).
mds_user_clear_cpu_buffers happens after sync_core, in your patchset,
if i am not mistaken.
Of course it does, mds_user_clear_cpu_buffers() is on exit, the
sync_core() is on entry.
quoted
quoted
quoted
+ /* NMI happens here and must still do/finish CT_WORK_n */
+ sync_core();
But after the discussion with you, it seems doing the TLB checking
and (also sync_core) checking very late/very early on exit/entry
makes things easier to review.
I don't know about late, it must happen *very* early in entry. The
sync_core() must happen before any self-modifying code gets called
(static_branch, static_call, etc..) with possible exception of the
context_tracking static_branch.
The TLBi must also happen super early, possibly while still on the
entry stack (since the task stack is vmap'ed).
But will it be ever be freed/remapped from other CPUs while the task
is running?
Probably not, still something we need to be really careful with.
quoted
We currently don't run C
code on the entry stack, that needs quite a bit of careful work to make
happen.
Was thinking of coding in ASM after (as early as possible) the write to
switch to kernel CR3:
No, we're not going to add new feature to ASM. You'll just have to wait
until all that gets lifted to C.
Kernel entry:
-------------
cpu = smp_processor_id();
if (isolation_enabled(cpu)) {
reqs = atomic_xchg(&percpudata->user_kernel_state, IN_KERNEL_MODE);
if (reqs & CPU_REQ_FLUSH_TLB)
flush_tlb_all();
if (reqs & CPU_REQ_SYNC_CORE)
sync_core();
}
Exit to userspace (as close to write to CR3 with user pagetable
pointer):
-----------------
cpu = smp_processor_id();
if (isolation_enabled(cpu)) {
atomic_or(IN_USER_MODE, &percpudata->user_kernel_state);
}
You think that is a bad idea (in ASM, not C) ?
Those atomics are a bad idea and not goig to happen.
quoted
We're not going to add an atomic to context tracking. There is one, we
just got to extract/share it with RCU.
Again, to avoid kernel TLB flushes you'd have to ensure:
I know how it works, but we're not going to add a second atomic to
entry/exit. RCU has one in there, that's going to be it. Again, we just
got to extract/share.