[Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

[Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

[Thomas Huth]

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 <thuth@redhat.com>
---
 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.

 hw/core/Makefile.objs  |  2 +-
 hw/core/null-machine.c | 27 +++++++++++++++++++++++++--
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
index a4c94e5..0b6c0f1 100644
--- a/hw/core/Makefile.objs
+++ b/hw/core/Makefile.objs
@@ -12,7 +12,6 @@ common-obj-$(CONFIG_XILINX_AXI) += stream.o
 common-obj-$(CONFIG_PTIMER) += ptimer.o
 common-obj-$(CONFIG_SOFTMMU) += sysbus.o
 common-obj-$(CONFIG_SOFTMMU) += machine.o
-common-obj-$(CONFIG_SOFTMMU) += null-machine.o
 common-obj-$(CONFIG_SOFTMMU) += loader.o
 common-obj-$(CONFIG_SOFTMMU) += qdev-properties-system.o
 common-obj-$(CONFIG_SOFTMMU) += register.o
@@ -20,3 +19,4 @@ common-obj-$(CONFIG_SOFTMMU) += or-irq.o
 common-obj-$(CONFIG_PLATFORM_BUS) += platform-bus.o
 
 obj-$(CONFIG_SOFTMMU) += generic-loader.o
+obj-$(CONFIG_SOFTMMU) += null-machine.o
diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
index 0351ba7..27c8369 100644
--- a/hw/core/null-machine.c
+++ b/hw/core/null-machine.c
@@ -13,18 +13,41 @@
 
 #include "qemu/osdep.h"
 #include "qemu-common.h"
+#include "qemu/error-report.h"
 #include "hw/hw.h"
 #include "hw/boards.h"
+#include "sysemu/sysemu.h"
+#include "exec/address-spaces.h"
+#include "cpu.h"
 
-static void machine_none_init(MachineState *machine)
+static void machine_none_init(MachineState *mch)
 {
+    CPUState *cpu = NULL;
+
+    /* Initialize CPU (if a model has been specified) */
+    if (mch->cpu_model) {
+        cpu = cpu_init(mch->cpu_model);
+        if (!cpu) {
+            error_report("Unable to initialize CPU");
+            exit(1);
+        }
+    }
+
+    /* RAM at address zero */
+    if (mch->ram_size) {
+        MemoryRegion *ram = g_new(MemoryRegion, 1);
+
+        memory_region_allocate_system_memory(ram, NULL, "ram", mch->ram_size);
+        memory_region_add_subregion(get_system_memory(), 0, ram);
+    }
 }
 
 static void machine_none_machine_init(MachineClass *mc)
 {
     mc->desc = "empty machine";
     mc->init = machine_none_init;
-    mc->max_cpus = 0;
+    mc->max_cpus = 1;
+    mc->default_ram_size = 0;
 }
 
 DEFINE_MACHINE("none", machine_none_machine_init)
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

[Eduardo Habkost]

On Wed, Jan 18, 2017 at 01:44:50PM +0100, 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 <thuth@redhat.com>

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>

I will wait for the opinion of others before applying it, though.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

[Alistair Francis]

On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth <thuth@redhat.com> 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 <thuth@redhat.com>
> ---
>  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.

Thanks,

Alistair

>
>  hw/core/Makefile.objs  |  2 +-
>  hw/core/null-machine.c | 27 +++++++++++++++++++++++++--
>  2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
> index a4c94e5..0b6c0f1 100644
> --- a/hw/core/Makefile.objs
> +++ b/hw/core/Makefile.objs
> @@ -12,7 +12,6 @@ common-obj-$(CONFIG_XILINX_AXI) += stream.o
>  common-obj-$(CONFIG_PTIMER) += ptimer.o
>  common-obj-$(CONFIG_SOFTMMU) += sysbus.o
>  common-obj-$(CONFIG_SOFTMMU) += machine.o
> -common-obj-$(CONFIG_SOFTMMU) += null-machine.o
>  common-obj-$(CONFIG_SOFTMMU) += loader.o
>  common-obj-$(CONFIG_SOFTMMU) += qdev-properties-system.o
>  common-obj-$(CONFIG_SOFTMMU) += register.o
> @@ -20,3 +19,4 @@ common-obj-$(CONFIG_SOFTMMU) += or-irq.o
>  common-obj-$(CONFIG_PLATFORM_BUS) += platform-bus.o
>
>  obj-$(CONFIG_SOFTMMU) += generic-loader.o
> +obj-$(CONFIG_SOFTMMU) += null-machine.o
> diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
> index 0351ba7..27c8369 100644
> --- a/hw/core/null-machine.c
> +++ b/hw/core/null-machine.c
> @@ -13,18 +13,41 @@
>
>  #include "qemu/osdep.h"
>  #include "qemu-common.h"
> +#include "qemu/error-report.h"
>  #include "hw/hw.h"
>  #include "hw/boards.h"
> +#include "sysemu/sysemu.h"
> +#include "exec/address-spaces.h"
> +#include "cpu.h"
>
> -static void machine_none_init(MachineState *machine)
> +static void machine_none_init(MachineState *mch)
>  {
> +    CPUState *cpu = NULL;
> +
> +    /* Initialize CPU (if a model has been specified) */
> +    if (mch->cpu_model) {
> +        cpu = cpu_init(mch->cpu_model);
> +        if (!cpu) {
> +            error_report("Unable to initialize CPU");
> +            exit(1);
> +        }
> +    }
> +
> +    /* RAM at address zero */
> +    if (mch->ram_size) {
> +        MemoryRegion *ram = g_new(MemoryRegion, 1);
> +
> +        memory_region_allocate_system_memory(ram, NULL, "ram", mch->ram_size);
> +        memory_region_add_subregion(get_system_memory(), 0, ram);
> +    }
>  }
>
>  static void machine_none_machine_init(MachineClass *mc)
>  {
>      mc->desc = "empty machine";
>      mc->init = machine_none_init;
> -    mc->max_cpus = 0;
> +    mc->max_cpus = 1;
> +    mc->default_ram_size = 0;
>  }
>
>  DEFINE_MACHINE("none", machine_none_machine_init)
> --
> 1.8.3.1
>
>

Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

[Thomas Huth]

On 18.01.2017 18:57, Alistair Francis wrote:
> On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth <thuth@redhat.com> 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 <thuth@redhat.com>
>> ---
>>  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.

 Thomas

Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

[Alistair Francis]

On Wed, Jan 18, 2017 at 10:56 AM, Thomas Huth <thuth@redhat.com> wrote:
> On 18.01.2017 18:57, Alistair Francis wrote:
>> On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth <thuth@redhat.com> 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 <thuth@redhat.com>
>>> ---
>>>  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 <alistair.francis@xilinx.com>

Thanks,

Alistair

>
>  Thomas
>
>

Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

[Eduardo Habkost]

On Wed, Jan 18, 2017 at 04:34:47PM -0800, Alistair Francis wrote:
> On Wed, Jan 18, 2017 at 10:56 AM, Thomas Huth <thuth@redhat.com> wrote:
> > On 18.01.2017 18:57, Alistair Francis wrote:
> >> On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth <thuth@redhat.com> 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 <thuth@redhat.com>
> >>> ---
> >>>  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 <alistair.francis@xilinx.com>

Thanks. I am going to apply this and include in my next pull
request.

-- 
Eduardo