On 04/02/2010 10:01 AM, Paolo Bonzini wrote:
On 04/01/2010 10:27 PM, Blue Swirl wrote:
It will not be safe to use kvm_enabled() in vl.c, so there needs to be
a target dependent helper. The call to kvm_init could remain in vl.c,
likewise it's not strictly needed to move kvm_allowed to arch_init.c.
Not really, because kvm_allowed _can_ be used from once-compiled
files. The attached patch makes kvm-all.c be compiled always, even if
!CONFIG_KVM; functions that require kvm are almost always omitted for
now (so checking kvm_enabled() is required to call them). However,
kvm_init is stubbed so that vl.c can call it.
In the future we could add more stubbing and ultimately do this
unconditionally:
#define kvm_enabled() kvm_allowed
With this patch vl.c can already be compiled once, but I did not
include it because it would conflict with my balloon.c series; I'm
doing enough rebasing these days. Also, qemu-kvm is a bit behind qemu
and all these patches are nightmares for the merges, so it's better
IMO if things are left to calm down a bit.
Having kvm-all.c compile with and without CONFIG_KVM is pretty ugly IMHO.
Is compiling vl.c once really that important of a goal? Wouldn't it be
better to split bits out of vl.c and have those compile once? Ideally,
vl.c should be so small that compiling per-target shouldn't matter.
Regards,
Anthony Liguori
They just caused problems with the poisoning check in patch 2/2.
Poisoning kvm_enabled is right, but poisoning kvm_allowed is overkill.
Paolo
