From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwmQq-0004Kn-Il for qemu-devel@nongnu.org; Wed, 01 Aug 2012 23:50:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwmQp-00020v-Fq for qemu-devel@nongnu.org; Wed, 01 Aug 2012 23:50:40 -0400 Received: from gate.crashing.org ([63.228.1.57]:59177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwmQp-0001zr-6B for qemu-devel@nongnu.org; Wed, 01 Aug 2012 23:50:39 -0400 Message-ID: <1343879428.6911.6.camel@pasglop> From: Benjamin Herrenschmidt Date: Thu, 02 Aug 2012 13:50:28 +1000 In-Reply-To: <87vch2nhn0.fsf@codemonkey.ws> References: <1343873409-8571-1-git-send-email-david@gibson.dropbear.id.au> <1343873409-8571-2-git-send-email-david@gibson.dropbear.id.au> <87vch2nhn0.fsf@codemonkey.ws> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/2] Allow QEMUMachine to override reset sequencing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: agraf@suse.de, qemu-devel@nongnu.org, David Gibson On Wed, 2012-08-01 at 21:37 -0500, Anthony Liguori wrote: > > But all of the DT initialization stuff that is leading to this > discussion in the first place is a gross hack to make a PV > architecture > work that took far too many short cuts. > > Building a DT in memory representing hardware instead of making things > discoverable is not how hardware works. It depends :-) Take a Power7 machine for example... the system & processor are actually initialized by the service processor which loads some kind of similar data structure into memory before starting the initial firmware :-) So from the P7 itself point of view, it starts with a memory based data structure pre-build. Also some processors have a pretty much turing complete "POR engine" which executes code from some kind of EEPROM to initialize the system, cores & busses on reset, which can involve writing things to memory as well (though it generally doesn't). > This sort of stuff is either > (1) hard coded in a firmware/flashrom or (2) built dynamically in > firmware. Let's not pretend like we're doing this because it's needed > for real hardware. Doesn't matter, we do things like -kernel which means pre-loading the kernel from qemu, even on x86. That doesn't match real HW either, but it's convenient to have. But overall there are real HW reasons to control the reset as well so the hook makes sense both ways. Cheers, Ben.