On 03/09/2010 02:54 PM, Alexander Graf wrote:
On 09.03.2010, at 13:50, Avi Kivity wrote:
On 03/08/2010 08:03 PM, Alexander Graf wrote:
Userspace can tell us that it wants to trigger an interrupt. But
so far it can't tell us that it wants to stop triggering one.
So let's interpret the parameter to the ioctl that we have anyways
to tell us if we want to raise or lower the interrupt line.
I asked for a KVM_CAP_ for this. What was the conclusion of that thread?
Uh - did we come to one?
The last thing you said about it was:
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.
So I assumed it'd be ok to not have one. If you like I can send an additional patch adding the CAP.
Well, what's the capability for this patchset?
Things like "if you have KVM_CAP_OSI you can assume you have
KVM_INTERRUPT_LOWER" don't work for me. A platform cap would be called
KVM_CAP_MOL and explicitly document everything in there.
And it commits you to not deprecating things individually. Really,
individual caps are better.
--
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
