From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsbsW-0006RF-K8 for qemu-devel@nongnu.org; Wed, 01 Feb 2012 10:13:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsbsQ-0006IR-FE for qemu-devel@nongnu.org; Wed, 01 Feb 2012 10:13:44 -0500 Received: from mail-pz0-f46.google.com ([209.85.210.46]:51140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsbsQ-0006IE-5x for qemu-devel@nongnu.org; Wed, 01 Feb 2012 10:13:38 -0500 Received: by dadp15 with SMTP id p15so1382259dad.33 for ; Wed, 01 Feb 2012 07:13:36 -0800 (PST) Message-ID: <4F29569A.7070504@codemonkey.ws> Date: Wed, 01 Feb 2012 09:13:30 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1328055113-30031-1-git-send-email-grant.likely@secretlab.ca> <201202010135.32078.paul@codesourcery.com> <1CB9FDC2-00A7-45BF-9693-21EB23FB47B1@suse.de> <4F28A554.4090000@codemonkey.ws> <4F29384F.6070404@codemonkey.ws> <4F293D40.90804@codemonkey.ws> <514AF576-4462-40FD-B6EA-F98C6AD4A915@suse.de> <4F2941BB.9010406@codemonkey.ws> <52CE60F2-1E45-4E46-8C53-0C1879093E6E@suse.de> <4F294398.8000506@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] arm: add device tree support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , qemu-devel@nongnu.org, Rob Herring , Grant Likely , Paul Brook , "Edgar E. Iglesias" , Jeremy Kerr , John Williams On 02/01/2012 07:55 AM, Alexander Graf wrote: > > On 01.02.2012, at 14:52, Anthony Liguori wrote: >> Fine, but to boot u-boot, the real hardware must set IP to something that's most likely an offset into ROM flash. >> >> Why can't we bootstrap semi-hosted mode by having a ROM somewhere that just redirects IP? >> >> It doesn't have to be a full blown u-boot. > > That would work, yes. > >> >>> >>> That's why I'm saying things don't work out all that simple with semi-hosted environments. Now you could argue that semi-hosting is a bad thing, but we'll always have to have it. On s390 for example, semi-hosting is how real hardware works. Or at least the parts that are visible to end users. Especially when you model PV machines, you'll have a hard time with fixed reset IPs too. >> >> s390 is a special case because "real hardware" is not actually real hardware. It's a VM. > > Sure, but how would we model things there? Our model needs to be flexible enough to cope with these oddballs. > > In fact, s390 is even more complicated. For DASD boot, the CPU is stalled at first and instead the DASD controller reads some instructions from memory that then bootstrap the bootloader. But IIUC that's only the case for DASD boot. For zfcp boot, you basically get semi-hosting. Once CPUs are modeled QOM, my expectation is that we'll have something like a CPU::halted property. As part of realize, a CPU would set halted = true and that is what would trigger the CPU execution (be it through TCG or KVM). There is no reason that on s390, the CPU realize function couldn't avoid setting halted=true and instead allow another device (with a wider view of the system) to perform some additional initialization work and then set the CPU halted property to true. This is all about what causes the system to start running. Once we move to a property realize() model, it gives us a lot more flexibility to work through these types of dependency issues. Regards, Anthony Liguori > > Alex > >