| Message ID | 1484743490-24721-1-git-send-email-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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 > >
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
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 > >
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.
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)
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(-)