Rusty Russell wrote:
On Mon, 2007-04-23 at 02:49 +0200, Andi Kleen wrote:
On Monday 23 April 2007 02:24:05 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.
It's a functional split, isn't it? arch/mm internal and "exported" to other
users
Hi,
When I said functional I was thinking "page table ops" vs "apic ops"
etc. There's little logic to what needs exporting.
Most modules only need the interrupt operations. A small handful want
more, and then some (kvm, lguest) need a whole range of crap (these
should use the native_ versions directly, since nested paravirt is not
supported).
I did the work before; I'll drag it back out and see what the symbols
are again...
Interrupt control is needed in general. CPUID is also widely used.
FPU control (clts, read / write cr0) is required for certain software
operations.
There are non-obvious exports that are required for some modules; in
particular, MSRs may be used in video drivers, and wbinvd must be
available to hardware drivers. We may wish to simply trap / emulate
these instructions and remove the paravirt-ops altogether. They are not
performance critical in 32-bit, and will complicate loading non-GPL
drivers for a wide range of hardware - hardware that is not exposed in a
virtualized environment to begin with.
Some rather more interesting modules map kernel page tables to read the
physical frame numbers from ptes; this is
safe to do if you get_pages or get_user_pages and keep the pages
locked. This requires kmap_atomic_pte to be available. Similarly,
pte_val and make_pte need to be available. Mostly only modules that
require a native environment (virtualization modules) need them, but we
need some way to either resolve the symbol as load time or make the
requirement for the symbol go away. No matter how you look at it,
failing to load a module because of an unresolved paravirt-op that is
actually going to be reduced to a nop is a very silly situation to be in.
Zach
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
