[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
From: |
Thomas Huth |
Subject: |
Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine |
Date: |
Thu, 26 Apr 2018 20:18:52 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
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 - since it's not that urgent that the raw cortex-m3 core is
usable with the none machine, is it?
Thomas