On 7/12/19 1:09 AM, Alexandre Chartre wrote: > On 7/12/19 12:38 AM, Dave Hansen wrote: >> I don't see the per-cpu areas in here. But, the ASI macros in >> entry_64.S (and asi_start_abort()) use per-cpu data. > > We don't map all per-cpu areas, but only the per-cpu variables we need. ASI > code uses the per-cpu cpu_asi_session variable which is mapped when an ASI > is created (see patch 15/26): No fair! I had per-cpu variables just for PTI at some point and had to give them up! ;) > + /* > + * Map the percpu ASI sessions. This is used by interrupt handlers > + * to figure out if we have entered isolation and switch back to > + * the kernel address space. > + */ > + err = ASI_MAP_CPUVAR(asi, cpu_asi_session); > + if (err) > + return err; > > >> Also, this stuff seems to do naughty stuff (calling C code, touching >> per-cpu data) before the PTI CR3 writes have been done. But, I don't >> see anything excluding PTI and this code from coexisting. > > My understanding is that PTI CR3 writes only happens when switching to/from > userland. While ASI enter/exit/abort happens while we are already in the > kernel, > so asi_start_abort() is not called when coming from userland and so not > interacting with PTI. OK, that makes sense. You only need to call C code when interrupted from something in the kernel (deeper than the entry code), and those were already running kernel C code anyway. If this continues to live in the entry code, I think you have a good clue where to start commenting. BTW, the PTI CR3 writes are not *strictly* about the interrupt coming from user vs. kernel. It's tricky because there's a window both in the entry and exit code where you are in the kernel but have a userspace CR3 value. You end up needing a CR3 write when you have a userspace CR3 value when the interrupt occurred, not only when you interrupt userspace itself.
