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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
