From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwZ44-0003Lx-Iu for qemu-devel@nongnu.org; Tue, 09 Jul 2013 10:38:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwZ43-0001KC-9W for qemu-devel@nongnu.org; Tue, 09 Jul 2013 10:38:48 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:59727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwZ43-0001K8-3T for qemu-devel@nongnu.org; Tue, 09 Jul 2013 10:38:47 -0400 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 9 Jul 2013 14:01:59 -0000 From: Anthony Liguori In-Reply-To: <1373345328.4446.115.camel@pasglop> References: <1372315560-5478-1-git-send-email-aik@ozlabs.ru> <1372315560-5478-3-git-send-email-aik@ozlabs.ru> <87fvvo29ps.fsf@codemonkey.ws> <51DB8639.9050906@ozlabs.ru> <1373345328.4446.115.camel@pasglop> Date: Tue, 09 Jul 2013 08:58:02 -0500 Message-ID: <871u776djp.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt , Alexey Kardashevskiy Cc: qemu-devel@nongnu.org, Alexander Graf , qemu-ppc@nongnu.org, Paolo Bonzini , Paul Mackerras , David Gibson Benjamin Herrenschmidt writes: > On Tue, 2013-07-09 at 13:40 +1000, Alexey Kardashevskiy wrote: >> No, why? It is a per CPU state of XICS controller, never exists apart >> from XICS. > > ICP is. ICS is ... different but can mostly be considered to be the > XICS itself. > > Anthony, we could be completely anal about it and create a gigantic > cathedral of devices or just be a bit realistic and do something simpler > that has the exact same functionality :) There's very little complexity in making something a device. It's just a matter of sticking a DeviceState member in the struct, changing the way the object is created (object_new vs. malloc), and adding a TypeInfo. There's a very good reason to have things be devices too. You can only control the section naming of devices for live migration. The only way to set compatibility properties for live migration is by having device properties too. You haven't dealt with these problems yet, but you will, and doing the work up front means that you don't have to break migration once in order to keep it compatible in the future. > Basically, in HW the layout of the interrupt network is: > > - One ICP per processor thread (the "presenter"). This contains the > registers to fetch a pending interrupt (ack), EOI, and control the > processor priority. > > - One ICS per logical source of interrupts (ie, one per PCI host > bridge, and a few others here or there). This contains the per-interrupt > source configuration (target processor(s), priority, mask) and the > per-interrupt internal state. This sounds an awful lot like the relationship between the I/O APIC(s) and the local APICs FWIW. > Under PAPR, there is a single "virtual" ICS ... somewhat (it's a bit > oddball what pHyp does here, arguably there are two but we can ignore > that distinction). There is no register level access. A pair of firmware > (RTAS) calls is used to configure each virtual interrupt. > > So our model here is somewhat the same. We have one ICS in the emulated > XICS which arguably *is* the emulated XICS, there's no point making it a > separate "device", that would just be gross, and each VCPU has an > associated ICP. There's nothing gross about making the things that are devices devices. Regards, Anthony Liguori > > Cheers, > Ben.