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.bennee@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)";
mc->init = machine_none_init;
mc->max_cpus = 1;
mc->default_ram_size = 0;
--
2.17.0
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.bennee@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
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).
Thomas
Thomas Huth <thuth@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.bennee@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?
> 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?
--
Alex Bennée
On 26.04.2018 18:09, Alex Bennée wrote:
>
> Thomas Huth <thuth@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.bennee@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 - since it's not that urgent that the raw cortex-m3 core is
usable with the none machine, is it?
Thomas
On 26 April 2018 at 19:18, Thomas Huth <thuth@redhat.com> wrote: > 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 The interrupt controller in an M-profile core is an integral part of the CPU itself (it happens to be accessible via memory-mapped accesses); our "nvic" object in QEMU also implements various other "core part of the CPU but the interface is memory mapped registers" functionality that isn't strictly part of the interrupt controller. A configuration which has an M profile CPU and does not have these registers and the interrupt controller isn't architecturally permitted and is just not right. We shouldn't let users configure QEMU that way. It's not really clear to me what the "none" machine is for, though... > or there just should be an error message instead of a crash > when the additional hardware is not available This would certainly be a good start. (M profile is significantly different from A profile in this area, which is why A profile doesn't crash here.) thanks -- PMM
Thomas Huth <thuth@redhat.com> writes:
> On 26.04.2018 18:09, Alex Bennée wrote:
>>
>> Thomas Huth <thuth@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.bennee@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
On 26.04.2018 20:44, Alex Bennée wrote:
>
> Thomas Huth <thuth@redhat.com> writes:
>
>> On 26.04.2018 18:09, Alex Bennée wrote:
>>>
>>> Thomas Huth <thuth@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.bennee@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, thinking about this again, what about something like:
"empty machine (for experts only)"
or:
"empty machine (use only if you know what you are doing)"
or something similar?
Thomas
On Thu, Apr 26, 2018 at 08:53:29PM +0200, Thomas Huth wrote:
> On 26.04.2018 20:44, Alex Bennée wrote:
> >
> > Thomas Huth <thuth@redhat.com> writes:
> >
> >> On 26.04.2018 18:09, Alex Bennée wrote:
> >>>
> >>> Thomas Huth <thuth@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.bennee@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, thinking about this again, what about something like:
>
> "empty machine (for experts only)"
>
> or:
>
> "empty machine (use only if you know what you are doing)"
>
> or something similar?
I think a note like this would be a good idea, but it would be
even better if we actually document the purpose and caveats of
-machine none on the man page.
--
Eduardo
On Thu, Apr 26, 2018 at 11:18 AM, Thomas Huth <thuth@redhat.com> wrote: > On 26.04.2018 18:09, Alex Bennée wrote: >> Thomas Huth <thuth@redhat.com> writes: >>> 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. xtensa sim machine is a bit more than just instruction simulator: it instantiates CPU-configuration-specific local memories. It is meant to be compatible with Xtensa ISS from Xtensa development tools. -- Thanks. -- Max
© 2016 - 2025 Red Hat, Inc.