On Sun, Jun 5, 2011 at 4:58 PM, Jan Kiszka <jan.kiszka@xxxxxx> wrote:
> 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().
>
OK, so let me try to get this straight.
We all agree that ruining the ABI is crazy - sorry about even putting
that out there.
On ARM, we are talking about IRQs and FIQs, both of which can be
lowered and raised. In other words, four values.
But instead of this, you want to use KVM_IRQ_LINE and just assume one
CPU to begin with and always assert/deassert the interrupts on that
CPU and later, with SMP support, you want to use KVM_SET_GSI_ROUTING
to control which CPU gets the interrupt - even though GSI is a
non-existing concept for ARM? (Also, I could not seem to find any use
of GSI_ROUTING in current upstream QEMU, but I may be missing
something here?).
I suggest I simply use a flag in the irq field on the kvm_interrupt
struct as suggested by Jan, for now, and if we start emulating GICs
inside the kernel for ARM we can go the extra mile at that point.
IMHO, I think the semantics of actually raising an interrup line on
the VCPU, as opposed to the VM, when it's CPU interrupt we are talking
about is equally important.
--
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
