Re: [RFC, PATCH 0/5] Paravirt: fix export of paravirt-ops to binary modules

[Jeremy Fitzhardinge <jeremy@goop.org>]

Rusty Russell wrote:
> On Mon, 2007-04-23 at 01:49 +0200, Andi Kleen wrote:
>   
>>> Less exports good.  Consistency with all config options isn't a hard
>>> requirement: I'd be tempted not to export the pte functions.
>>>       
>> Yes paravirt_ops should be probably split into two for internal and external
>> available functions. Any takers? 
>>     
>
> Hi Andi!
>
> 	I'm a little uncomfortable with cutting the struct this way: I always
> thought it'd be a function split if we did one.
>
> 	With the new patch code we could simply shuffle all the exportables to
> the front and fail to patch calls past this point (then fail the module
> load).
>
> I'll see what I can come up with...

There was some discussion about hybrid paravirt/fully virt hypervisor
models at the Xen summit.  There are definitely some interesting things
you can do by having a mostly paravirtualized guest running within an
hvm container.

One of the things I was considering as a result was splitting the
privileged instruction ops (all the cr?, msr, segment stuff) into a
cpu_ops, and putting the pagetable stuff into pagetable_ops.  That would
make a broad split of shadow vs direct pagetables and hvm vs non-hvm
models pretty straightforward, and probably sharing more interfaces than
they might otherwise.

    J