| Message ID | 20180425153343.24023-1-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] hw/core: expand description of null-machine | expand |
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 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
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
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;
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(-) -- 2.17.0