Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 31 Mar 2021 15:45:09 -0700 | Subject | Re: Candidate Linux ABI for Intel AMX and hypothetical new related features |
| |
On Wed, Mar 31, 2021 at 3:28 PM Len Brown <lenb@kernel.org> wrote: > > On Wed, Mar 31, 2021 at 12:53 PM Andy Lutomirski <luto@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
| |