qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] Change qemu_set_irq() to return status info


From: Gleb Natapov
Subject: Re: [Qemu-devel] [PATCH 1/3] Change qemu_set_irq() to return status information.
Date: Sun, 29 Jun 2008 22:44:12 +0300

On Sun, Jun 29, 2008 at 07:11:01PM +0100, Paul Brook wrote:
> On Sunday 29 June 2008, Gleb Natapov wrote:
> > On Sun, Jun 29, 2008 at 03:38:10PM +0100, Paul Brook wrote:
> > > On Sunday 29 June 2008, Gleb Natapov wrote:
> > > > The return value is less then zero if interrupt is masked, zero if it
> > > > is known that interrupt is lost (due to coalescing) or greater then
> > > > zero if interrupt is delivered or was successfully queued for delivery
> > > > by interrupt controller. Device emulation can use this info as it
> > > > pleases. Included patch adds detection of interrupt coalescing into PIC
> > > > and APIC code for edge triggered interrupts.
> > >
> > > This is woefully incomplete, and obviously hasn't been tested on anything
> > > other than x86 targets.
> >
> > Yes, you are right. It was not tested on anything other than x86. Do you
> > see why this approach will not work on other architectures? Can you
> > elaborate on what current patch is missing for other architectures
> > support? 
> 
> Well, if nothing else there's 40+ interrupt controllers that need fixing up 
> before it'll even compile cleanly (mismatching function prototypes are IMHO 
> not acceptable).
Yes. 60 actually. I'll fix all of them.

> 
> > The initial goal is to fix RTC/PIT problem on x86 while do not 
> > hurt any other architectures in any way.
> 
> Well, you're introducing a fair amount of churn, so it'd better work for 
> other 
> architectures too. Otherwise we're liable to have to rewrite it later.  I 
> can't say offhand whether your approach will work on other architectures. 
> qemu has quite a wide variety of interrupt controllers and timers, you should 
> check whether they fit into your model.
> 
The model takes into account that not all interrupt controller are
capable to detect missed interrupt (it is possible that there is no
interrupt controller at all). In this case irq function should
return one and everything will fall back to how it works now.

--
                        Gleb.




reply via email to

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