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

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

[Alex Bennée]

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

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

[Thomas Huth]

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

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

[Alex Bennée]

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

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

[Thomas Huth]

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

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

[Peter Maydell]

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

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

[Alex Bennée]

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

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

[Thomas Huth]

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

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

[Eduardo Habkost]

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

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

[Max Filippov]

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