On 06/05/2011 05:13 PM, Jan Kiszka wrote:
On 2011-06-05 14:21, Avi Kivity wrote:
> On 06/03/2011 06:53 PM, Jan Kiszka wrote:
>> >> @@ -310,6 +310,7 @@ struct kvm_translation {
>> >> struct kvm_interrupt {
>> >> /* in */
>> >> __u32 irq;
>> >> + __u8 raise;
>> >> };
>> >
>> > This touches an existing ABI and corrupts the definition of
>> > KVM_INTERRUPT IOCTL. The might exist jurisdictions considering this a
>> > capital crime. :)
>> >
>> > You rather have to define a new CPU IRQ injection interface that
>> > supports both raising and lowering
>
> This is KVM_IRQ_LINE:
>
It's so far associated with in-kernel irqchip input pins, not with
raising CPU IRQs.
It's up to the architecture to define what it's connected to.
Note that with KVM_SET_GSI_ROUTING (bad name for ARM...) we can even
choose if an irq line is connected to a kernel-emulated interrupt
controller or to the core's irq input.
>> and declare its availability via a
>> > KVM_CAP. Don't forget to make it extensible (flags field) so that
>> future
>> > requirements can be added without breaking existing users.
>>
>> Or much easier (this is what PowerPC is doing): Define irq values in a
>> way that they include a raise/lower flag.
>
> Much easier and much horribler.
>
Less horrible than overloading KVM_IRQ_LINE IMHO. The semantics of
kvm_interrupt::irq are in arch hands anyway.
Something that can be raised or lowered is an irq line.
--
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
