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

[Alistair Francis <alistair.francis@xilinx.com>]

On Sun, Jan 15, 2017 at 11:59 PM, Thomas Huth <thuth@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
>
>