This header file has some utility functions which implement per-ISA logic for handling locking.

This CL moves those functions into methods on the ISA object:

https://gem5-review.googlesource.com/c/public/gem5/+/48384/4

Since those functions are not called frequently, the small overhead of having to go to the ISA object to run them should not be meaningful.

As Andreas has pointed out, this isn't really the right place for these functions to live, particularly since as he says the locking is more of a global situation, but the code to maintain it is in a per-thread object, but I think it's currently the best place.

Also, CPUs which delegate how they work to other systems (KVM, fast model) may or may not actually have ISA objects, or at least meaningful ones. By putting this interface on the ISA class, we're kind of forcing them to have one, even if it's a weird fork of the native version.

I think how the ISA object is structured and how the components of the CPU come together need a refactoring, but fortunately there is essentially no harm in doing that after moving these functions instead of before.