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

Reply via email to