Messages in this thread | | | From | Len Brown <> | Date | Wed, 31 Mar 2021 18:28:27 -0400 | Subject | Re: Candidate Linux ABI for Intel AMX and hypothetical new related features |
| |
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.
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.
We've also established that when running in a VMM, every update to XCR0 causes a VMEXIT.
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.
| |