Re: [kvm-devel] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support

[Avi Kivity]

Paul Brook wrote:
> On Monday 24 March 2008, Avi Kivity wrote:
>   
> > Paul Brook wrote:
> >     
> > > On Sunday 23 March 2008, Dor Laor wrote:
> > >       
> > > > --- a/qemu/hw/irq.c
> > > > +++ b/qemu/hw/irq.c
> > > > @@ -30,6 +30,8 @@ struct IRQState {
> > > >      int n;
> > > >  };
> > > >
> > > > +uint32_t qemu_irq_acked[NR_IRQ_WORDS];
> > > >         
> > > This is absolute rubbish. The whole point of the IRQ framework is that it
> > > doesn't assume a single flat IRQ controller.
> > >       
> > x86 does have a single irq space (even when using cascaded pics or
> > multiple ioapics), called gsi (for generalized system interrupt, or
> > something).  It is possible to enumerate all irqs on all platforms that
> > have a finite number of them.
> >     
>
> Sure, it's possible to enumerate all the possible IRQ inputs (it's effectively 
> the same as enumerating all the IRQ sources). It's not possible to say 
> anything particularly useful about that enumeration though.
> It's not uncommon for interrupts to be connected to GPIO pins, be inverted, or 
> have interrupt routings that change dynamically.
>
>   

Right, but...

> > It may be better though to identify an irq by a (controller_id,
> > irq_line) pair instead.
> >     
>
> That's what qemu_irq is for. Anything else is IMHO wrong.
>   

In the case of a kernel virtualization module (like kqemu of kvm) that 
is able to handle interrupt injection, qemu_irq is not sufficient since 
it is not visible to the kernel.  We need some serialization that can 
pass the user/kernel boundary.  For x86 gsi is a satisfactory serialization.

Even for a pure qemu solution, qemu_irq is difficult to work with.  For 
the x86 case, we know which vector was successfully injected, and we 
need to work out which qemu_irq caused it.  This is not deterministic in 
the general case (since several irq lines can cause the same vector to 
be injected, and since the irq->vector mapping can change), so any 
solution will involve heuristics.

--
error compiling committee.c: too many arguments to function