Thomas Huth <th...@redhat.com> writes: > On 26.04.2018 18:09, Alex Bennée wrote: >> >> Thomas Huth <th...@redhat.com> 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 <alex.ben...@linaro.org> >>>> --- >>>> 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