From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cUgOE-0002wz-Er for qemu-devel@nongnu.org; Fri, 20 Jan 2017 16:06:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cUgO9-00066p-Hm for qemu-devel@nongnu.org; Fri, 20 Jan 2017 16:06:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34214) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cUgO9-00066F-AA for qemu-devel@nongnu.org; Fri, 20 Jan 2017 16:06:25 -0500 Date: Fri, 20 Jan 2017 19:06:21 -0200 From: Eduardo Habkost Message-ID: <20170120210621.GC21555@thinpad.lan.raisama.net> References: <1484743490-24721-1-git-send-email-thuth@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alistair Francis Cc: Thomas Huth , Peter Maydell , Markus Armbruster , "qemu-devel@nongnu.org Developers" , Laurent Vivier , Max Filippov , Paolo Bonzini On Wed, Jan 18, 2017 at 04:34:47PM -0800, Alistair Francis wrote: > On Wed, Jan 18, 2017 at 10:56 AM, Thomas Huth wrote: > > On 18.01.2017 18:57, Alistair Francis wrote: > >> On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth wrote: > >>> Sometimes it is useful to have just a machine with CPU and RAM, without > >>> any further hardware in it, e.g. if you just want to do some instruction > >>> debugging for TCG with a remote GDB attached to QEMU, or run some embedded > >>> code with the "-semihosting" QEMU parameter. qemu-system-m68k already > >>> features a "dummy" machine, and xtensa a "sim" machine for exactly this > >>> purpose. > >>> All target architectures have nowadays also a "none" machine, which would > >>> be a perfect match for this, too - but it currently does not allow to add > >>> CPU and RAM yet. Thus let's add these possibilities in a generic way to the > >>> "none" machine, too, so that we hopefully do not need additional "dummy" > >>> machines in the future anymore (and maybe can also get rid of the already > >>> existing "dummy"/"sim" machines one day). > >>> Note that the default behaviour of the "none" machine is not changed, i.e. > >>> no CPU and no RAM is instantiated by default. You have explicitely got to > >>> specify the CPU model with "-cpu" and the amount of RAM with "-m" to get > >>> these new features. > >>> > >>> Signed-off-by: Thomas Huth > >>> --- > >>> v3: > >>> - Get rid of the cpu_init_def() wrapper again, make null-machine.o > >>> target dependent instead and use cpu_init() directly. > >>> - Omit the loader code for the "-kernel" option for now (users can > >>> use "-device loader,..." instead). We can add code for the -kernel > >>> parameter later (either an implementation or a warning), once we've > >>> decided how it should behave for the "none" machine. > >> > >> I think there should at least be a warning to start with though. It > >> seems confusing that no errors are reported but the argument is > >> ignored. > > > > I'm still rather in favor of adding the hunk here that calls the generic > > loader for "-kernel" ... anyway, we can add either behavior with a later > > patch. So far the "none" machine never reported an error here, so this > > is not a regression if we do not have this right from the start. > > Your right, it isn't a regression. I still think we should try to get > some sort of action in there before the next release. > > Reviewed-by: Alistair Francis Thanks. I am going to apply this and include in my next pull request. -- Eduardo