Jeremy Fitzhardinge wrote:
Well, the BUG is if the patch-size is smaller than sizeof(indirect
call). Or more generally, if the patch site contains bogus crud. But I
don't think checking for that in the patcher makes a great deal of sense.
True, it may not make a lot of sense to check there. But it is the only
place where we can check it at runtime. Unless you want some kind of
compile time checking in the code which generates the patch data, say
perhaps a .abort. Still, that is not safe against modules which have
broken paravirt-ops embedding.
Currently the invariants on pv_ops patch sites are initially:
1. the sequence is always at least an indirect call to an
implementation of the operations, and
2. it will always have appropriate register save/restores which allow
a call to C code to work at that site
As a result, it is always OK to execute without doing any patching.
The callsite clobbers may be smaller than those needed for a naked C
call, but that means the site will have push/pops around the indirect
call. This gives the patcher more space to work with if it wants to
inline something; if it just wants to generate a call to C code, it must
also generate its own register saves.
Since there are so few of these sites, and they are performance
critical, the placement of a BUG() here verifying the clobbers are ok
effectively makes it the paravirt-op backend's responsibility to ensure
that these sites get patched. This is what would allow the removal of
dependence on the paravirt_ops symbol for the most important interrupt
control operations.
It's semantically no different from updating the paravirt_ops structure
followed by patching. If the kernel comes up with all the sites
prelinked to the native versions, then its the same as booting on the
current kernel, with paravirt_ops initialized to the native versions.
It's semantically the same, but the code needs to be re-usable later,
which is where the problems arise - you can't simply cram the prelink
code into head.S, but have to write it to be properly callable later on.
Zach
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
