From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyhnI-0006bA-KB for qemu-devel@nongnu.org; Mon, 15 Jul 2013 08:22:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyhnH-0000xn-7Q for qemu-devel@nongnu.org; Mon, 15 Jul 2013 08:22:20 -0400 Received: from cantor2.suse.de ([195.135.220.15]:39029 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyhnG-0000xT-U1 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 08:22:19 -0400 Message-ID: <51E3E979.2040607@suse.de> Date: Mon, 15 Jul 2013 14:22:17 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <51E3C6FB.8070302@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Morph cpu_reset -> device_reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Christian Borntraeger , Anthony Liguori , "qemu-devel@nongnu.org Developers" , Peter Maydell Am 15.07.2013 12:45, schrieb Peter Crosthwaite: > Hi Andreas, >=20 > On Mon, Jul 15, 2013 at 7:55 PM, Andreas F=E4rber wr= ote: >> Hi Peter, >> >> Am 15.07.2013 06:02, schrieb Peter Crosthwaite: >>> A while ago, TYPE_CPU was refactored to by a child of TYPE_DEVICE. As >>> something of a hangover though, CPU has a separate reset fn to device= . >>> This means >>> >>> device_reset(DEVICE(my_cpu)); >>> >>> doesn't actually work as a reset. Should we fix this by getting rif o= f >>> cpu_reset and just using the device reset API for cpu reset? >> >> This question has come up a number of times, cf. the archives. For one= , >> CPU reset is a mess with most CPUs not registering reset handlers of >> their own like devices do but having machines do that and piggy-back >> some machine-specific initialization, possibly even relying on executi= on >> order of reset handlers. >=20 > So some architectures are going to be a lot easier than others and if > this is considered the right thing to do, we can convert some of easy > ones and scratch our heads later re the machine quirks. I can speak > for Microblaze as being as easy one. ARM doesn't look that scary > either - and thats the one I want to convert for my application. See hw/arm/boot.c for where such piggy-backing happens in ARM. >> For another, some forms of Soft Reset (e.g., >> kdump on s390x) will require to reset devices only but not CPUs - >> currently qdev_devices_reset() calls all reset handlers, not just >> devices as the name might imply. >> >> For now you can reset a CPU via >> >> cpu_reset(CPU(my_cpu)); >> >=20 > So my application is clock controllers, which have a uniform reset > mechanism. I want to avoid having to give my clock controller CPU > awareness for the sake of being able to do a reset. Infact, I dont > event want my controller know what its resetting, all it gets is a > link to a TYPE_DEVICE which it can then reset. Not possible with CPUs > unless you: >=20 > if (object_dynamic_cast(my_dev, TYPE_CPU)) > cpu_reset(...); > else > device_reset(...); Sounds what you are looking for is rather a qemu_irq pin, which Anthony has been promoting for soft resets, too. Note that if we made device_reset() work on a CPU then we would need to place that type check elsewhere still. 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