On Wed, Mar 31, 2021 at 3:28 PM Len Brown <l...@kernel.org> wrote:
>
> On Wed, Mar 31, 2021 at 12:53 PM Andy Lutomirski <l...@amacapital.net> wrote:
>
> > But this whole annotation thing will require serious compiler support.
> > We already have problems with compilers inlining functions and getting
> > confused about attributes.
>
> We added compiler annotation for user-level interrupt handlers.
> I'm not aware of it failing, or otherwise being confused.
I followed your link and found nothing. Can you elaborate? In the
kernel, we have noinstr, and gcc gives approximately no help toward
catching problems.
>
> Why would compiler support for fast-signals be any more "serious"?
>
> > An API like:
> >
> > if (get_amx()) {
> > use AMX;
> > } else {
> > don’t;
> > }
> >
> > Avoids this problem. And making XCR0 dynamic, for all its faults, at least
> > helps force a degree of discipline on user code.
>
> dynamic XCR0 breaks the installed base, I thought we had established that.
I don't think this is at all established. If some code thinks it
knows the uncompacted XSTATE size and XCR0 changes, it crashes. This
is not necessarily a showstopper.
>
> We've also established that when running in a VMM, every update to
> XCR0 causes a VMEXIT.
This is true, it sucks, and Intel could fix it going forward.
>
> I thought the goal was to allow new programs to have fast signal handlers.
> By default, those fast signal handlers would have a stable state
> image, and would
> not inherit large architectural state on their stacks, and could thus
> have minimal overhead on all hardware.
That is *a* goal, but not necessarily the only goal.
--Andy
