On Sun, Jan 15, 2017 at 11:59 PM, Thomas Huth <th...@redhat.com> wrote: > On 14.01.2017 12:03, Laurent Vivier wrote: >> Le 14/01/2017 à 07:51, Thomas Huth a écrit : >>> 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, RAM or a kernel 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've explicitely got to >>> specify the CPU model with "-cpu" and the amount of RAM with "-m" to get >>> these new features. >> >> Did you try to use the generic-loader to load the kernel? >> >> Something like "-device loader,file=vmlinux" instead of adding this part >> in the none machine? > > It does not work by default - because we need a way to set the CPU's > program counter to the entry point of the ELF file.
The -device loader logic can set the PC to the entry point of the ELF. You just need to specify 'cpu-num=x' when loading the file. > But I think the users also expect the "-kernel" parameter to be working, > so I think we should add the loader code in null-machine.c anyway. I agree that uses probably expect the '-kernel' option to work as well. Thanks, Alistair > >> Perhaps we could also add a cpu this way, as they are already available >> in the device list for the machine that allows hotplug. > > The only machine that allows hot-plugging of CPUs with the device > interface is ppc64 spapr, as far as I know. So this does not help with > embedded boards like m68k or xtensa. Also I think you need some > additional magic like a bus where the CPUs could be attached, and maybe > firmware interfaces, so this does not fit the idea of an embedded board > very well. > >> With the same idea, we could also have a "-device ram,size=XXX" to add >> ram (not DIMM). > > That might be useful indeed, but mainly because some embedded boards > expect some additinal RAM at a higher, non-zero addresses, too. > >> I think is is the idea behind the none machine: > [...] >> This >> also provides a mode that we can use in the future to construct machines >> entirely through QMP commands. > > We're still very far away from the possibility that everything could be > constructed on the fly. (Embedded) CPUs, RAM, buses ... all that is not > really pluggable yet. So I think my patch is a good first step into this > direction to get at least an initial playground for a machine that can > be defined by the user. > > Thomas > >
