From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDCvI-0000ug-HS for qemu-devel@nongnu.org; Wed, 06 Mar 2013 06:54:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDCvH-0004Vq-5X for qemu-devel@nongnu.org; Wed, 06 Mar 2013 06:54:16 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36245 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDCvG-0004Vb-Sv for qemu-devel@nongnu.org; Wed, 06 Mar 2013 06:54:15 -0500 Message-ID: <51372E63.10905@suse.de> Date: Wed, 06 Mar 2013 12:54:11 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1362510056-3316-1-git-send-email-pbonzini@redhat.com> <1362510056-3316-2-git-send-email-pbonzini@redhat.com> <513708BE.2000407@redhat.com> In-Reply-To: <513708BE.2000407@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 1/3] cpu: make CPU_INTERRUPT_RESET available on all targets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Peter Crosthwaite , lersek@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, dwmw2@infradead.org Am 06.03.2013 10:13, schrieb Paolo Bonzini: > Il 06/03/2013 03:02, Peter Crosthwaite ha scritto: >> If you truly have connectivity from device land to the CPU cluster >> should that be reflected by some sort of QOM linkage? >=20 > I think in real hardware what happens is that a single "wire" is > distributed to all CPUs. Devices do not have direct links to all the > CPUs, they are agnostic of how many CPUs they control (at least on x86)= . > In this sense, using first_cpu is the right modelling in my opinion. >=20 > Having qemu_irqs for all the reset requests would definitely be a good > thing to do. In the meanwhile, however, having half of the reset > signals as qemu_irqs, and the other half as function calls would be > confusing. >=20 > Alternatively we could add some kind of "meta-device" that distributes > stuff to all CPUs, and hide the usage of first_cpu there. Andreas, wha= t > do you think? In short I think that first_cpu is ugly but we do not have a CPU_FOREACH() macro/function replacement yet. That's why I like the approach of defining a qemu_reset_cpus() function (or whatever we name it) that hides this rather than everyone open-coding it, which has recently led to some conversion mistakes on my part. I don't see a working way to model 1:n link ATM. Having a "cpu-resetter" object with a QOM reset method distributing cpu_reset/cpu_interrupt seems unnecessarily complicated to me. Seeing that qemu_irq was going to be replaced with a QOM Pin object, I don't see an advantage in trying to introduce new qemu_irqs where a simple function call works just as well. You could decide this on a case-by-case basis depending on whether the reset is level-triggered. Or dig out Anthony's Pin series and do something based on that. ;-) But mostly my concerns are not introducing new per-target global functions and keeping/making CPU reset code sane in terms of not getting duplicated into multiple places, i.e. code sharing and consolidation, if we start differentiating between hard and soft and whatever reset types. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg