Re: [RFC, PATCH 5/5] Paravirt_ops export.patch

[Zachary Amsden <zach@vmware.com>]

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