From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwkjN-0000ha-3r for qemu-devel@nongnu.org; Tue, 09 Jul 2013 23:06:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwkjL-0004D2-S8 for qemu-devel@nongnu.org; Tue, 09 Jul 2013 23:06:13 -0400 Received: from mail-gg0-f180.google.com ([209.85.161.180]:56402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwkjL-0004Co-Oe for qemu-devel@nongnu.org; Tue, 09 Jul 2013 23:06:11 -0400 Received: by mail-gg0-f180.google.com with SMTP id i6so2204853ggm.39 for ; Tue, 09 Jul 2013 20:06:10 -0700 (PDT) Message-ID: <51DCCF9A.2040401@ozlabs.ru> Date: Wed, 10 Jul 2013 13:06:02 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 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> <871u776djp.fsf@codemonkey.ws> In-Reply-To: <871u776djp.fsf@codemonkey.ws> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Alexander Graf , qemu-ppc@nongnu.org, Paolo Bonzini , Paul Mackerras , David Gibson On 07/09/2013 11:58 PM, Anthony Liguori wrote: > 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. I have got a problem right now. I need to have 2 devices - xics and xics-kvm, give them the same VMState properties and migration names and have different pre_load/post_load (btw the whole point of separating xics-kvm from xics). How do I solve this without anyone saying that I am doing terribly a wrong thing? I already asked this in "[Qemu-devel] [PATCH 05/17] pseries: savevm support for XICS interrupt controller" but have not seen any response yet. Thank you. >> 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. -- Alexey