From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37254 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmFz1-000270-B1 for qemu-devel@nongnu.org; Thu, 19 Aug 2010 21:01:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmFz0-0005rx-7X for qemu-devel@nongnu.org; Thu, 19 Aug 2010 21:01:23 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:48115) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmFz0-0005rs-1B for qemu-devel@nongnu.org; Thu, 19 Aug 2010 21:01:22 -0400 Received: by ywa6 with SMTP id 6so1023416ywa.4 for ; Thu, 19 Aug 2010 18:01:21 -0700 (PDT) Message-ID: <4C6DD3DE.506@codemonkey.ws> Date: Thu, 19 Aug 2010 20:01:18 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup References: <4C6D86F9.3010602@codemonkey.ws> <4C6D98E7.9020109@codemonkey.ws> <4C6DA75D.40303@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Blue Swirl , "Liu >> \"Liu, Jinsong\"" , Paul Brook , Avi Kivity , qemu-devel On 08/19/2010 05:52 PM, malc wrote: >> Yes, but the programming model was different. >> >> Look at the PIC compared to the lapic. The PIC is programmed via pio at a >> fixed location. There is only one PIC and it interacts with the system just >> like all other devices. IOW, there is no reference to CPUState. >> > There are two PICs actually there's a cascade.. > Technically speaking, originally there was just one and then more IRQs were supported by cascading and reserving an IRQ line for supporting cascading. I think you can technical cascade with any IRQ and have more than one slave but the historic PC architecture only had one slave AFAIK. Regards, Anthon Liguori >> When you look at the local APIC (apic.c) however, you see that it's the only >> device in the tree that actually interacts with a CPUState. The notion of >> cpu_get_current_apic() is a good example of the tricks needed to make this >> work. >> >> The local APIC is a cpu feature, not a device. >> >> Regards, >> >> Anthony Liguori >> >> >