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. 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. > 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
