On 03/08/2010 04:01 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 03/08/2010 03:55 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 03/08/2010 03:48 PM, Alexander Graf wrote:
How does userspace know they exist?
#ifdef KVM_INTERRUPT_SET? MOL is the only user of this so far. And
that
won't work without the hypervisor call anyways.
We generally compile on one machine, and run on another.
So? Then IRQ unsetting doesn't work. Without this series you won't get
much further than booting the kernel anyways because XER is broken, TLB
flushes are broken and FPU loading is broken. So not being able to unset
an IRQ line is the least of your problems :).
There's a difference between an error message telling you to upgrade
to a kernel with KVM_CAP_BLAH and a failure. It's the difference
between a bug report and silence.
I see. So we can check for KVM_CAP_PPC_OSI and know that it's in the
same patch series, also making KVM_INTERRUPT_XXX work, right? Or do you
really want to have 500 capabilities for every single patch?
Having individual capabilities makes backporting a lot easier (otherwise
you have to backport the whole thing). If the changes are logically
separate, I prefer 500 separate capabilities.
However, for a platform bringup, it's okay to have just one capability,
assuming none of the changes are applicable to other platforms.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
