Re: [patch] paravirt: isolate module ops

[Zachary Amsden <zach@vmware.com>]

Arjan van de Ven wrote:
>> I would suggest a slightly different carving.  For one, no TLB flushes.  
>> If you can't modify PTEs, why do you need to have TLB flushes?  And I 
>> would allow CR0 read / write for code which saves and restores FPU state 
>>     
>
> no that is abstracted away by kernel_fpu_begin/end. Modules have no
> business doing that themselves
>   

As long as they don't rely on inlines for that... checking and 
kernel_fpu_end is inline and uses stts(), which requires CR0 read / 
write.  One can easily imagine binary modules which do use the fpu, and 
these were not broken before, so breaking them now seems the wrong thing 
to do.

I agree on debug registers - anything touching them is way too shady.  
And there is no reason modules should be doing raw page table 
operations, they should use proper mm functions and leave the page 
details to the mm layer, which doesn't do these things inline.

Basically, it is just the things that do get inlined that I think we 
should worry about.  If you all feel strongly that this should be fixed 
in 2.6.20, perhaps the best thing to do is in fact 
EXPORT_SYMBOL_GPL(paravirt_ops), and we can queue up a patch in -mm 
which will export those paravirt_ops required inline by modules for 
2.6.21.  Otherwise, I think there will be too many rejects against the 
paravirt code in Andrew's tree.

Zach