[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Brook
Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support
Date: Mon, 24 Mar 2008 13:45:27 +0000
User-agent: KMail/1.9.9

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.

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]