Re: [PATCH V3 10/10] x86/pks: Add PKS test code

Dan Williams
2020-12-18T16:59:31Z

On Thu, Dec 17, 2020 at 8:05 PM Ira Weiny <ira.weiny@intel.com> wrote:
>
> On Thu, Dec 17, 2020 at 12:55:39PM -0800, Dave Hansen wrote:
> > On 11/6/20 3:29 PM, ira.weiny@intel.com wrote:
> > > + /* Arm for context switch test */
> > > + write(fd, "1", 1);
> > > +
> > > + /* Context switch out... */
> > > + sleep(4);
> > > +
> > > + /* Check msr restored */
> > > + write(fd, "2", 1);
> >
> > These are always tricky. What you ideally want here is:
> >
> > 1. Switch away from this task to a non-PKS task, or
> > 2. Switch from this task to a PKS-using task, but one which has a
> > different PKS value
>
> Or both...
>
> >
> > then, switch back to this task and make sure PKS maintained its value.
> >
> > *But*, there's no absolute guarantee that another task will run. It
> > would not be totally unreasonable to have the kernel just sit in a loop
> > without context switching here if no other tasks can run.
> >
> > The only way you *know* there is a context switch is by having two tasks
> > bound to the same logical CPU and make sure they run one after another.
>
> Ah... We do that.
>
> ...
> + CPU_ZERO(&cpuset);
> + CPU_SET(0, &cpuset);
> + /* Two processes run on CPU 0 so that they go through context switch. */
> + sched_setaffinity(getpid(), sizeof(cpu_set_t), &cpuset);
> ...
>
> I think this should be ensuring that both the parent and the child are
> running on CPU 0. At least according to the man page they should be.
>
> <man>
> A child created via fork(2) inherits its parent's CPU affinity mask.
> </man>
>
> Perhaps a better method would be to synchronize the 2 threads more to ensure
> that we are really running at the 'same time' and forcing the context switch.
>
> > This just gets itself into a state where it *CAN* context switch and
> > prays that one will happen.
>
> Not sure what you mean by 'This'? Do you mean that running on the same CPU
> will sometimes not force a context switch? Or do you mean that the sleeps
> could be badly timed and the 2 threads could run 1 after the other on the same
> CPU? The latter is AFAICT the most likely case.
>

One way to guarantee that both threads run is to just pass a message
between them over a pipe and wait for the submitter to receive an ack
from the other end.