Re: QEMU PIC indirection patch for in-kernel APIC work

[Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Gregory Haskins wrote:
>>>> On Wed, Apr 4, 2007 at 10:20 AM, in message <4613B438.60107-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>,
>>>>         
> Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote: 
>   
>> The devices are already written to take a set_irq function.  Instead of 
>> hijacking the emulated PIC device, I think it would be better if in 
>> pc.c, we just conditionally created our PIC device that reflected to the 
>> hypervisor and passed the appropriate function to the emulated hardware.
>>
>>     
>
> When I first starting looking at the code, I was hoping to do exactly that.  But unfortunately it appears as though many devices call pic_set_irq() directly which is why I used the approach I did.  Take a look at qemu/hw/rt18139.c for an example. 
>   

Yeah, I was thinking of serial.c specifically.  I just looked again and 
things are not quite as clean as I had thought.

PPC has a set_irq hook but it also has it's own pic_set_irq function.

I suspect the cleanest thing to do would be to register an irq handler 
that takes an callback/opaque.  Probably switch pic_set_irq calls to 
qemu_set_irq or something.

But this is definitely a topic to bring up on qemu-devel as it touches 
all architectures.

Regards,

Anthony Liguori

>   
>> Otherwise, to support all the other architectures, there's going to be a 
>> lot of modifications.
>>     
>
> Fully agree, which is why I waited for review before putting in all that work ;)
>
> -Greg
>
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV