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
