From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6LNN-0005PF-KY for qemu-devel@nongnu.org; Tue, 28 Aug 2012 08:58:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6LNG-0001GX-8G for qemu-devel@nongnu.org; Tue, 28 Aug 2012 08:58:37 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:41757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6LNG-0001GK-2O for qemu-devel@nongnu.org; Tue, 28 Aug 2012 08:58:30 -0400 From: Paul Brook Date: Tue, 28 Aug 2012 13:58:22 +0100 References: <1346099868-7774-1-git-send-email-meadori@codesourcery.com> <1346099868-7774-4-git-send-email-meadori@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <201208281358.23742.paul@codesourcery.com> Subject: Re: [Qemu-devel] [PATCH v1 3/4] hw: Deduce the default machine from the specified CPU model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Meador Inge , qemu-devel@nongnu.org > > This changes the driver behavior to choose the default machine > > model based on the CPU being used. Defaulting the machine this > > way makes it easier to use QEMU as an ISS by just specifying > > the -cpu option since a default machine that is suitable for > > emulating the full ISA can be chosen. > > > > For example, currently on ARM the ARM Integrator/CP board is > > chosen as the default machine when specifying just a CPU. > > However, this doesn't work well when passing -cpu cortex-m3 > > since on ARMv7-M processors the NVIC is a part of the architecture > > and is needed to support instructions like SVC. > > Personally I'd rather we didn't support a "default machine" at > all, at least for ARM. It does matter what board you run on, > so you need to specify. A possible compromise is to only accept -cpu if -M is also specified. > Just to pick an obvious example, you can't stick a core > which supports VFPv4 (the A15 is the only one we have) into > the integratorcp Yes you can. Your OS probably doesn't support it, and you might have trouble persuading the OS vendor to support something that doesn't physically exist, but those are a competely separate problems. > We could reasonably add patches which made boards error > out if you tried to use them with unsupported CPUs, I guess. That suffers from a large fuzzy region containing interesting combinations that could/do work, but will probably never be created in silicon. If done properly this the QOM conversion should give you this for free. Paul