Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine

[Alex Bennée]

Thomas Huth <address@hidden> writes:

> On 26.04.2018 18:09, Alex Bennée wrote:
>>
>> Thomas Huth <address@hidden> writes:
>>
>>> On 25.04.2018 17:33, Alex Bennée wrote:
>>>> People following old instructions for QEMU get the message "No machine
>>>> specified, and there is no default" and run -machine help to pick a
>>>> new machine. Lay people might consider the null-machine to be such a
>>>> basic starting point but they won't get far. This leads to confusion,
>>>> see https://bugs.launchpad.net/qemu/+bug/1766896 as an example.
>>>>
>>>> I'm open to better words - I figured "THIS PROBABLY ISN'T WHAT YOU
>>>> WANT" seemed less helpful though.
>>>>
>>>> Signed-off-by: Alex Bennée <address@hidden>
>>>> ---
>>>>  hw/core/null-machine.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
>>>> index cde4d3eb57..72f0815045 100644
>>>> --- a/hw/core/null-machine.c
>>>> +++ b/hw/core/null-machine.c
>>>> @@ -50,7 +50,7 @@ static void machine_none_init(MachineState *mch)
>>>>
>>>>  static void machine_none_machine_init(MachineClass *mc)
>>>>  {
>>>> -    mc->desc = "empty machine";
>>>> +    mc->desc = "empty machine (for probing/QMP)";
>>>
>>> Actually, with certain CPUs, you can really use the "none" machine as a
>>> pure instruction set testing system. For example, on m68k, there used to
>>> be an explicit "dummy" machine for this job, and we removed it in favour
>>> of the "none" machine:
>>>
>>> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=22f2dbe7eaf3e12e38c9c210
>>
>> Ahh OK. Do you know what other CPUs can be used in this way?
>
> I think it should be possible with at least all the boards that have a
> "sim" machine, e.g. xtensa, mips, moxie and openrisc.
>
>>> So I'd rather not add such wording. We should rather fix those segfaults
>>> instead (QEMU should never segfault - in case a device can not be used
>>> with the "none" machine, there rather should be an error message instead).
>>
>> Hmm the ARM world is complicated by peripherals that are on-chip but not
>> part of the "CPU". I wonder if this is a edge case for our modelling?
>> Should for example -cpu cortex-m3 imply additional peripherals and how
>> do we handle that in the -m none case?
>
> I don't think it makes sense to instantiate e.g. an interrupt controller
> with the "none" machine automatically ... so the raw cortex-m3 core
> should either be usable without that, too, or there just should be an
> error message instead of a crash when the additional hardware is not
> available

Well I think this is where out abstraction breaks down. The cortex-m3 is
an ARMv7 core but with a bunch of stuff also on the SoC, including an
IRQ controller and MPU. However these devices are instantiated as part
of the machine model.

> - since it's not that urgent that the raw cortex-m3 core is
> usable with the none machine, is it?

No although it would theoretically be possible to use a cortex-m3 on
it's own with nothing else but some RAM and some buffers for it's serial
ports. Currently -cpu cortex-m3 will fail hard if not instantiated with
a m3 aware machine model.

--
Alex Bennée