On 4/22/07, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
Doing nothing is a BUG, even before this change. If you can't patch in a properly virtualizable substitute for a non-virtualizable sequence, the kernel will not work. The only way for the patching to fail is for lack of space or failure to meet clobber constraints, both of which would be fatal even without the patching.
I thought a lot about it and ended up concluding it was not tenable. I can't recall quite the logic that got me there now, but I do know that two things immediately spring to mind:
1) Using the linker, all paravirt-ops, even performance critical ones, become function calls, with 3 clobbered registers. Thwarting this by using non-C function calls brings you directly back to the fancy inline assembly goo you are trying to avoid.
2) You must support dynamic re-linking - the kernel has to boot and use builtin native style operations before switching over to the virtualized operations. So you have to have some kind of jettisonable early binding support.
Considering the performance element will be explored fully, I'm not sure that using the linker results in any reduction in complexity.
Zach
Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:
> Hm, OK, I see what you're getting at.
>
> I guess the BUG_ON()s need only fire if they're failing to patch over a
> ud2a instruction.
>
>
> I'm in two minds about this. On the one hand, it's a clever hack which
> does achieve the desired outcome. On the other hand, it turns an
> optimisation mechanism into a special-purpose ad-hoc linker which
> doesn't seem like quite the right way to go. The conversion from "best
> effort, doing nothing is OK" to "doing nothing is a BUG" behaviour is a
> good indication of this.
Doing nothing is a BUG, even before this change. If you can't patch in a properly virtualizable substitute for a non-virtualizable sequence, the kernel will not work. The only way for the patching to fail is for lack of space or failure to meet clobber constraints, both of which would be fatal even without the patching.
Yes. Has anyone thought more about David Miller's suggesting of just
using the linker and not doing the fancy binary replacement?
I thought a lot about it and ended up concluding it was not tenable. I can't recall quite the logic that got me there now, but I do know that two things immediately spring to mind:
1) Using the linker, all paravirt-ops, even performance critical ones, become function calls, with 3 clobbered registers. Thwarting this by using non-C function calls brings you directly back to the fancy inline assembly goo you are trying to avoid.
2) You must support dynamic re-linking - the kernel has to boot and use builtin native style operations before switching over to the virtualized operations. So you have to have some kind of jettisonable early binding support.
Zach
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
