From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjnVy-0007gc-Mq for qemu-devel@nongnu.org; Mon, 12 May 2014 06:31:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjnVt-0004Fa-P3 for qemu-devel@nongnu.org; Mon, 12 May 2014 06:31:22 -0400 Message-ID: <5370A2EB.10604@redhat.com> Date: Mon, 12 May 2014 12:31:07 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1399041202-26184-1-git-send-email-pbonzini@redhat.com> <1399041202-26184-7-git-send-email-pbonzini@redhat.com> <53707C9E.7000205@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 6/8] cpu: make CPU_INTERRUPT_RESET available on all targets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , =?UTF-8?B?QW5kcmVhcyBGw6RyYg==?= =?UTF-8?B?ZXI=?= Cc: QEMU Developers , Alexander Graf , Christian Borntraeger , qemu-ppc , Anthony Liguori , Richard Henderson Il 12/05/2014 11:41, Peter Maydell ha scritto: > On 12 May 2014 08:47, Andreas F=C3=A4rber wrote: >> Am 02.05.2014 16:33, schrieb Paolo Bonzini: >>> On the x86, some devices need access to the CPU reset pin (INIT#). >>> Provide a generic service to do this, using one of the internal >>> cpu_interrupt targets. Generalize the PPC-specific code for >>> CPU_INTERRUPT_RESET to other targets. >>> >>> Since PPC does not support migration across QEMU versions (its >>> machine types are not versioned yet), I picked the value that >>> is used on x86, CPU_INTERRUPT_TGT_INT_1. Consequently, TGT_INT_2 >>> and TGT_INT_3 are shifted down by one while keeping their value. > >> No objection from my side, but I thought there had been agreement amon= g >> Anthony, Peter and others that soft-reset is nothing generic that can = be >> implemented as API? >> >> s390x has multiple ways to do resets, same for ppc, and I thought the >> suggested way to implement them was a qemu_irq in the particular piece >> of hardware together with custom reset functions as done for s390x? > > I think the right way to expose reset to the outside world is via > a qemu_irq line, yes, but possibly the implementation inside the > CPU object might use a CPU_INTERRUPT_* bit (compare the way > that ARM IRQ and FIQ are qemu_irq lines to the outside world > but operate by just setting bits for the mainloop to check). Ok, I'll queue patches 1-7 and rewrite patch 8 to use a qemu_irq. > This patch also seems to be eliding the difference between > "reset signal asserted, stop doing stuff" and "reset signal > deasserted, start executing code again". In the x86 architecture it is actually not defined whether the reset is=20 edge-triggered or level-triggered, so that's okay I think. Paolo