Re: [patch v5 2/8] add prctl task isolation prctl docs and samples

[Frederic Weisbecker]

On Wed, Oct 27, 2021 at 02:52:47PM -0300, Marcelo Tosatti wrote:
> On Wed, Oct 27, 2021 at 02:38:06PM +0200, Frederic Weisbecker wrote:
> > > +        The 'pmask' argument specifies the location of an 8 byte mask
> > > +        containing which features should be activated. Features whose
> > > +        bits are cleared will be deactivated. The possible
> > > +        bits for this mask are:
> > > +
> > > +                - ``ISOL_F_QUIESCE``:
> > > +
> > > +                Activate quiescing of background kernel activities.
> > > +                Quiescing happens on return to userspace from this
> > > +                system call, and on return from subsequent
> > > +                system calls (unless quiesce_oneshot_mask is configured,
> > > +                see below).
> > > +
> > > +        If the arg3 argument is non-zero, it specifies a pointer to::
> > > +
> > > +         struct task_isol_activate_control {
> > > +                 __u64 flags;
> > > +                 __u64 quiesce_oneshot_mask;
> > 
> > So you are using an entire argument here to set a single feature (ISOL_F_QUIESCE).
> 
> Yes, but there is room at "struct task_isol_activate_control" for other features 
> to use (and additional space in the remaining prctl arguments, if necessary).

Ok but we have a configuration syscall and an activation syscall. Why bothering
with config parts on activation syscall?


> 
> > It looks like the oneshot VS every syscall behaviour should be defined at
> > configuration time for individual ISOL_F_QUIESCE features.
> 
> It seems one-shot selection is dependent on the 
> application logic:
> 
> 	configure task isolation
> 	enable oneshot quiescing of kernel activities
> 	do {
> 		process data (no system calls)
> 		if (event) {
> 			process event with syscalls
> 			enable oneshot quiescing of kernel activities
> 		}
>        } while (!exit_condition);
> 
> Considering configuration performed outside the application (by chisol),
> is the administrator supposed to know the internals of the application
> at this level ?

If the launcher doesn't know about details, just leave them to the isolated
app. I mean we have a syscall to get the configured features, it's easy to
modify their configuration and set the oneshot mode on the place wanted
by the isolated app.

> 
> What if the application desires to use one-shot in a section
> (of code) and "all syscalls" for another section.

Doesn't sound like a problem.

> 
> > Also do we want that to always apply to all syscalls? Should we expect corner
> > cases with some of them? 
> 
> What type of corner cases do you think of?

I don't trust my imagination enough to display all possible user workloads.

> 
> > What about exceptions and interrupts?
> 
> Should move the isolation_exit_to_user_mode_prepare call from
> __syscall_exit_to_user_mode_work to exit_to_user_mode_prepare.
> Good point.
> 
> About your question. Think so, because otherwise: 
> 
>      enable oneshot quiescing of kernel activities
>      do {
>              process data (no system calls)	    <--- 1. IRQ/exception
>              if (event) {
>                      process event with syscalls
>                      enable oneshot quiescing of kernel activities
>              }
>      } while (exit_condition == false);
> 
> 
> If either an interrupt or exception occurs at point 1 above, userspace
> might not be notified, and the interrupt/exception handler might 
> change state in the kernel which makes the current CPU a target
> for IPIs, for example changing per-CPU vm statistics.

Ok but please leave configuration space to modify that in the future just in case.

Thanks.