Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes: > On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote: >> > The idea is _NOT_ that you go look for references to the paravirt_ops >> > members structure, that would be stupid and you wouldn't be able to >> > use the most efficient addressing mode on a given cpu, you'd be >> > patching up indirect calls and crap like that. Just say no... >> >> That wouldn't handle inlines though. At least some of the current >> paravirtops like cli/sti are critical enough to require inlining. > > Well, we'd patch the inline over the call if we have room. > > Magic patching would be neat, but the downsides are that (1) we can't > expand the patching room and (2) there's no way of attaching clobber > info to the call site (doing register liveness analysis is not > appealing). True. You can use all of the call clobbered registers. > Now, this may not be fatal. 5 bytes is enough for all the native ops to > be patched inline. For lguest this covers popf and pushf, but not cli > and sti (10 bytes): they'd have to be calls. > > As for clobber info, it turns out that almost all of the calls can > clobber %eax, which is probably enough. We just need to mark the > handful of asm ones where this isn't true. I guess if the code is larger than a function call I'm failing to see the disadvantage in making it a direct function call. Any modern processor ought to be able to predict it perfectly, and processors like the P4 may even optimize the call out of their L1 instruction cache. If what David is suggesting works, making all of these direct calls looks easy and very maintainable. At which point patching instructions inline is quite possibly overkill. Is it truly critical to inline any of these instructions? Eric _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
