All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
@ 2018-04-25 15:33 Alex Bennée
  2018-04-25 15:52 ` Thomas Huth
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Bennée @ 2018-04-25 15:33 UTC (permalink / raw)
  To: qemu-devel
  Cc: peter.maydell, Alex Bennée, Eduardo Habkost, Marcel Apfelbaum

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

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-25 15:33 [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine Alex Bennée
@ 2018-04-25 15:52 ` Thomas Huth
  2018-04-26 16:09   ` Alex Bennée
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Huth @ 2018-04-25 15:52 UTC (permalink / raw)
  To: Alex Bennée, qemu-devel
  Cc: Marcel Apfelbaum, peter.maydell, Eduardo Habkost

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-25 15:52 ` Thomas Huth
@ 2018-04-26 16:09   ` Alex Bennée
  2018-04-26 18:18     ` Thomas Huth
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Bennée @ 2018-04-26 16:09 UTC (permalink / raw)
  To: Thomas Huth; +Cc: qemu-devel, Marcel Apfelbaum, peter.maydell, Eduardo Habkost


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-26 16:09   ` Alex Bennée
@ 2018-04-26 18:18     ` Thomas Huth
  2018-04-26 18:31       ` Peter Maydell
                         ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Thomas Huth @ 2018-04-26 18:18 UTC (permalink / raw)
  To: Alex Bennée
  Cc: Marcel Apfelbaum, peter.maydell, qemu-devel, Eduardo Habkost

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-26 18:18     ` Thomas Huth
@ 2018-04-26 18:31       ` Peter Maydell
  2018-04-26 18:44       ` Alex Bennée
  2018-04-26 18:55       ` Max Filippov
  2 siblings, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2018-04-26 18:31 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Alex Bennée, Marcel Apfelbaum, QEMU Developers, Eduardo Habkost

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-26 18:18     ` Thomas Huth
  2018-04-26 18:31       ` Peter Maydell
@ 2018-04-26 18:44       ` Alex Bennée
  2018-04-26 18:53         ` Thomas Huth
  2018-04-26 18:55       ` Max Filippov
  2 siblings, 1 reply; 9+ messages in thread
From: Alex Bennée @ 2018-04-26 18:44 UTC (permalink / raw)
  To: Thomas Huth; +Cc: Marcel Apfelbaum, peter.maydell, qemu-devel, Eduardo Habkost


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-26 18:44       ` Alex Bennée
@ 2018-04-26 18:53         ` Thomas Huth
  2018-05-03 19:29           ` Eduardo Habkost
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Huth @ 2018-04-26 18:53 UTC (permalink / raw)
  To: Alex Bennée
  Cc: Marcel Apfelbaum, peter.maydell, qemu-devel, Eduardo Habkost

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-26 18:18     ` Thomas Huth
  2018-04-26 18:31       ` Peter Maydell
  2018-04-26 18:44       ` Alex Bennée
@ 2018-04-26 18:55       ` Max Filippov
  2 siblings, 0 replies; 9+ messages in thread
From: Max Filippov @ 2018-04-26 18:55 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Alex Bennée, Marcel Apfelbaum, Peter Maydell, qemu-devel,
	Eduardo Habkost

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine
  2018-04-26 18:53         ` Thomas Huth
@ 2018-05-03 19:29           ` Eduardo Habkost
  0 siblings, 0 replies; 9+ messages in thread
From: Eduardo Habkost @ 2018-05-03 19:29 UTC (permalink / raw)
  To: Thomas Huth; +Cc: Alex Bennée, Marcel Apfelbaum, peter.maydell, qemu-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-05-03 19:29 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-25 15:33 [Qemu-devel] [RFC PATCH] hw/core: expand description of null-machine Alex Bennée
2018-04-25 15:52 ` Thomas Huth
2018-04-26 16:09   ` Alex Bennée
2018-04-26 18:18     ` Thomas Huth
2018-04-26 18:31       ` Peter Maydell
2018-04-26 18:44       ` Alex Bennée
2018-04-26 18:53         ` Thomas Huth
2018-05-03 19:29           ` Eduardo Habkost
2018-04-26 18:55       ` Max Filippov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.