On 2011-06-05 16:18, Avi Kivity wrote:
> 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.
Makes some sense: Add KVM_IRQ_ROUTING_CPU, and kvm_irq_routing_entry's
union would require some struct kvm_irq_routing_cpu containing the
target identifier.
However, I would recommend to carefully check the generic irq routing
bits before use - if they still contain some x86/ia64 specifics or
unwanted irqchip_in_kernel().
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
