Rusty Russell wrote: >> So if you have to do inlining for both a read and write CR accessors, >> doesn't it seem easier to just do them all and be gone with the stub >> implementations? Having a common approach is what led us down the patch >> of full blown patching, as it was easier to maintain than an ad-hoc set >> of interfaces selected simply by virtue of being on the critical path. >> The critical paths are quite a bit different on 64-bit as well, which >> means things like CR8 and WRMSR become important to inline. >> > > I still think there's significant benefit in the call implementations. > The first is that we can apply the patches over them at almost any time, > and the second is that their implementation is optional (good for > debugging). Mainly, though, it's because having them there is trivial. > > I'm not convinced that the maintenance burden of only patching some > insns is greater than patching them all... > I'm not completely convinced one way or the other. Symmetry comes to mind, which is why it seems easier to take either one approach or the other, rather than a mix. It is clear that inlining and patching is necessary for performance of some "instructions". >> In either case, letting the kernel decide which interfaces to complicate >> with inline patching could be the best solution - but we'd have to be >> careful to require non-virtualizable interfaces (or interfaces which >> require memory trapping) to always provide patchable alternatives. >> > > I don't understand the last half of this sentence. What were you > thinking of? AFAICT patching is always a performance optimization, > never a correctness requirement? > I misspoke a bit. Functional substitution is a correctness requirement for the non-virtualizable instructions and code sequences. Patching is an optional extension to the interface. If you have an indirection layer of any kind, that suffices for correctness. Always calling out to a stub implementation satisfies this requirement. Optionally calling out for only performance related concerns does not. Interfaces that require memory trapping can have a very bad effect on performance, hence, we would always like to have the facility of indirection for these interfaces as well. So it was not strictly the patching I was referring to. It is the mandatory indirection which is required for both correctness and performance. The idea that only performance critical instructions should be treated with special indirection is false, and that is what I would like to make clear. Not that anything in your patches or what you have said have suggested this, but it is a common misinterpretation I would like other people to avoid. Zach
