12:15 p.m.
- Deprecate the 'raspi4b' machine name, renaming it as
'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g' otherwise.
- Add the 'raspi4b-4g' and 'raspi4b-8g' machines, with
respectively 4GB and 8GB of DRAM.
Philippe Mathieu-Daudé (7):
hw/arm/raspi4b: Declare machine types using DEFINE_TYPES() macro
hw/arm/raspi4b: Introduce abstract raspi4-base machine type
hw/arm/raspi4b: Split raspi4b_machine_class_init() in two (1g and 2g)
hw/arm/raspi4b: Rename as raspi4b-1g / raspi4b-2g, deprecating old
name
hw/arm/raspi4b: Expose the raspi4b-1g machine on 64-bit hosts
hw/arm/raspi4b: Add the raspi4b-4g machine
hw/arm/raspi4b: Add the raspi4b-8g machine
docs/about/deprecated.rst | 6 +++
hw/arm/raspi4b.c | 91 +++++++++++++++++++++++++++++++--------
2 files changed, 79 insertions(+), 18 deletions(-)
--
2.47.1
12:15 p.m.
New subject: [PATCH 1/7] hw/arm/raspi4b: Declare machine types using DEFINE_TYPES() macro
When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. Since
we are going to add more machines, convert type_init()
by DEFINE_TYPES().
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
hw/arm/raspi4b.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index 1264e0d6eed..5c78d26f957 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -121,16 +121,13 @@ static void raspi4b_machine_class_init(ObjectClass *oc, void *data)
mc->init = raspi4b_machine_init;
}
-static const TypeInfo raspi4b_machine_type = {
- .name = TYPE_RASPI4B_MACHINE,
- .parent = TYPE_RASPI_BASE_MACHINE,
- .instance_size = sizeof(Raspi4bMachineState),
- .class_init = raspi4b_machine_class_init,
+static const TypeInfo raspi4_machine_types[] = {
+ {
+ .name = TYPE_RASPI4B_MACHINE,
+ .parent = TYPE_RASPI_BASE_MACHINE,
+ .instance_size = sizeof(Raspi4bMachineState),
+ .class_init = raspi4b_machine_class_init,
+ },
};
-static void raspi4b_machine_register_type(void)
-{
- type_register_static(&raspi4b_machine_type);
-}
-
-type_init(raspi4b_machine_register_type)
+DEFINE_TYPES(raspi4_machine_types)
--
2.47.1
12:15 p.m.
New subject: [PATCH 2/7] hw/arm/raspi4b: Introduce abstract raspi4-base machine type
In preparation of adding more machines based on the raspi4,
introduce TYPE_RASPI4_MACHINE. Remove TYPE_RASPI4B_MACHINE
definitions, declaring the machine name in place via the
MACHINE_TYPE_NAME("raspi4b") macro.
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
hw/arm/raspi4b.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index 5c78d26f957..548059f6d69 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -23,8 +23,8 @@
#include "hw/arm/bcm2838.h"
#include <libfdt.h>
-#define TYPE_RASPI4B_MACHINE MACHINE_TYPE_NAME("raspi4b")
-OBJECT_DECLARE_SIMPLE_TYPE(Raspi4bMachineState, RASPI4B_MACHINE)
+#define TYPE_RASPI4_MACHINE MACHINE_TYPE_NAME("raspi4-base")
+OBJECT_DECLARE_SIMPLE_TYPE(Raspi4bMachineState, RASPI4_MACHINE)
struct Raspi4bMachineState {
RaspiBaseMachineState parent_obj;
@@ -93,7 +93,7 @@ static void raspi4_modify_dtb(const struct arm_boot_info *info, void
*fdt)
static void raspi4b_machine_init(MachineState *machine)
{
- Raspi4bMachineState *s = RASPI4B_MACHINE(machine);
+ Raspi4bMachineState *s = RASPI4_MACHINE(machine);
RaspiBaseMachineState *s_base = RASPI_BASE_MACHINE(machine);
RaspiBaseMachineClass *mc = RASPI_BASE_MACHINE_GET_CLASS(machine);
BCM2838State *soc = &s->soc;
@@ -123,11 +123,15 @@ static void raspi4b_machine_class_init(ObjectClass *oc, void *data)
static const TypeInfo raspi4_machine_types[] = {
{
- .name = TYPE_RASPI4B_MACHINE,
+ .name = MACHINE_TYPE_NAME("raspi4b"),
+ .parent = TYPE_RASPI4_MACHINE,
+ .class_init = raspi4b_machine_class_init,
+ }, {
+ .name = TYPE_RASPI4_MACHINE,
.parent = TYPE_RASPI_BASE_MACHINE,
.instance_size = sizeof(Raspi4bMachineState),
- .class_init = raspi4b_machine_class_init,
- },
+ .abstract = true,
+ }
};
DEFINE_TYPES(raspi4_machine_types)
--
2.47.1
12:15 p.m.
New subject: [PATCH 3/7] hw/arm/raspi4b: Split raspi4b_machine_class_init() in two (1g and 2g)
Current raspi4b_machine_class_init() method register 2 distinct
machines, with different board revision (thus different memory
size), whether the host is 32-bit or more. Split it as 2 new
methods, one for the raspi4b with 1GB of memory (on 32-bit hosts)
and another for the raspi4b with 2GB of memory.
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
hw/arm/raspi4b.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index 548059f6d69..4ea79ec7092 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -107,26 +107,45 @@ static void raspi4b_machine_init(MachineState *machine)
raspi_base_machine_init(machine, &soc->parent_obj);
}
-static void raspi4b_machine_class_init(ObjectClass *oc, void *data)
+#if HOST_LONG_BITS == 32
+static void raspi4b_1g_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
RaspiBaseMachineClass *rmc = RASPI_BASE_MACHINE_CLASS(oc);
-#if HOST_LONG_BITS == 32
rmc->board_rev = 0xa03111; /* Revision 1.1, 1 Gb RAM */
-#else
- rmc->board_rev = 0xb03115; /* Revision 1.5, 2 Gb RAM */
-#endif
+
raspi_machine_class_common_init(mc, rmc->board_rev);
mc->init = raspi4b_machine_init;
}
+#else
+static void raspi4b_2g_machine_class_init(ObjectClass *oc, void *data)
+{
+ MachineClass *mc = MACHINE_CLASS(oc);
+ RaspiBaseMachineClass *rmc = RASPI_BASE_MACHINE_CLASS(oc);
+
+
+ rmc->board_rev = 0xb03115; /* Revision 1.5, 2 Gb RAM */
+ raspi_machine_class_common_init(mc, rmc->board_rev);
+ mc->init = raspi4b_machine_init;
+}
+#endif
static const TypeInfo raspi4_machine_types[] = {
+#if HOST_LONG_BITS == 32
{
.name = MACHINE_TYPE_NAME("raspi4b"),
.parent = TYPE_RASPI4_MACHINE,
- .class_init = raspi4b_machine_class_init,
- }, {
+ .class_init = raspi4b_1g_machine_class_init,
+ },
+#else
+ {
+ .name = MACHINE_TYPE_NAME("raspi4b"),
+ .parent = TYPE_RASPI4_MACHINE,
+ .class_init = raspi4b_2g_machine_class_init,
+ },
+#endif
+ {
.name = TYPE_RASPI4_MACHINE,
.parent = TYPE_RASPI_BASE_MACHINE,
.instance_size = sizeof(Raspi4bMachineState),
--
2.47.1
12:15 p.m.
New subject: [PATCH 4/7] hw/arm/raspi4b: Rename as raspi4b-1g / raspi4b-2g, deprecating old name
On 32-bit hosts, rename 'raspi4b' -> 'raspi4b-1g' to clarify the
machine has 1GB of RAM.
On 64-bit hosts, rename 'raspi4b' -> 'raspi4b-2g'.
Keep the 'raspi4b' alias but deprecate it.
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
docs/about/deprecated.rst | 6 ++++++
hw/arm/raspi4b.c | 6 ++++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 4a3c302962a..d635bd60d74 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -257,6 +257,12 @@ Big-Endian variants of MicroBlaze ``petalogix-ml605`` and
``xlnx-zynqmp-pmu`` ma
Both ``petalogix-ml605`` and ``xlnx-zynqmp-pmu`` were added for little endian
CPUs. Big endian support is not tested.
+ARM ``raspi4b`` machine (since 10.0)
+''''''''''''''''''''''''''''''''''''
+
+This machine has been renamed ``raspi4b-1g`` on 32-bit hosts and ``raspi4b-2g``
+on 64-bit ones.
+
Backend options
---------------
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index 4ea79ec7092..713b4693a49 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -117,6 +117,7 @@ static void raspi4b_1g_machine_class_init(ObjectClass *oc, void
*data)
raspi_machine_class_common_init(mc, rmc->board_rev);
mc->init = raspi4b_machine_init;
+ mc->alias = "raspi4b";
}
#else
static void raspi4b_2g_machine_class_init(ObjectClass *oc, void *data)
@@ -128,19 +129,20 @@ static void raspi4b_2g_machine_class_init(ObjectClass *oc, void
*data)
rmc->board_rev = 0xb03115; /* Revision 1.5, 2 Gb RAM */
raspi_machine_class_common_init(mc, rmc->board_rev);
mc->init = raspi4b_machine_init;
+ mc->alias = "raspi4b";
}
#endif
static const TypeInfo raspi4_machine_types[] = {
#if HOST_LONG_BITS == 32
{
- .name = MACHINE_TYPE_NAME("raspi4b"),
+ .name = MACHINE_TYPE_NAME("raspi4b-1g"),
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_1g_machine_class_init,
},
#else
{
- .name = MACHINE_TYPE_NAME("raspi4b"),
+ .name = MACHINE_TYPE_NAME("raspi4b-2g"),
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_2g_machine_class_init,
},
--
2.47.1
5:30 p.m.
New subject: [PATCH 4/7] hw/arm/raspi4b: Rename as raspi4b-1g / raspi4b-2g,
deprecating old name
On 1/2/25 10:15, Philippe Mathieu-Daudé wrote:
On 32-bit hosts, rename 'raspi4b' -> 'raspi4b-1g'
to clarify the
machine has 1GB of RAM.
On 64-bit hosts, rename 'raspi4b' -> 'raspi4b-2g'.
Keep the 'raspi4b' alias but deprecate it.
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
docs/about/deprecated.rst | 6 ++++++
hw/arm/raspi4b.c | 6 ++++--
2 files changed, 10 insertions(+), 2 deletions(-)
static const TypeInfo raspi4_machine_types[] = {
#if HOST_LONG_BITS == 32
{
- .name = MACHINE_TYPE_NAME("raspi4b"),
+ .name = MACHINE_TYPE_NAME("raspi4b-1g"),
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_1g_machine_class_init,
},
#else
{
- .name = MACHINE_TYPE_NAME("raspi4b"),
+ .name = MACHINE_TYPE_NAME("raspi4b-2g"),
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_2g_machine_class_init,
},
Forgot to squash here:
-- >8 --
diff --git a/tests/functional/test_aarch64_raspi4.py
b/tests/functional/test_aarch64_raspi4.py
index 7a4302b0c5a..891a8135b6b 100755
--- a/tests/functional/test_aarch64_raspi4.py
+++ b/tests/functional/test_aarch64_raspi4.py
@@ -37 +37 @@ def test_arm_raspi4(self):
- self.set_machine('raspi4b')
+ self.set_machine('raspi4b-1g')
@@ -67 +67 @@ def test_arm_raspi4_initrd(self):
- self.set_machine('raspi4b')
+ self.set_machine('raspi4b-1g')
---
12:15 p.m.
New subject: [PATCH 5/7] hw/arm/raspi4b: Expose the raspi4b-1g machine on 64-bit hosts
There is no particular reason to not have the raspi4b-1g machine
available on 64-bit hosts, so expose it there.
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
hw/arm/raspi4b.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index 713b4693a49..59b0d2ced44 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -107,7 +107,6 @@ static void raspi4b_machine_init(MachineState *machine)
raspi_base_machine_init(machine, &soc->parent_obj);
}
-#if HOST_LONG_BITS == 32
static void raspi4b_1g_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
@@ -117,9 +116,12 @@ static void raspi4b_1g_machine_class_init(ObjectClass *oc, void
*data)
raspi_machine_class_common_init(mc, rmc->board_rev);
mc->init = raspi4b_machine_init;
+#if HOST_LONG_BITS == 32
mc->alias = "raspi4b";
+#endif
}
-#else
+
+#if HOST_LONG_BITS > 32
static void raspi4b_2g_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
@@ -131,22 +133,21 @@ static void raspi4b_2g_machine_class_init(ObjectClass *oc, void
*data)
mc->init = raspi4b_machine_init;
mc->alias = "raspi4b";
}
-#endif
+#endif /* HOST_LONG_BITS > 32 */
static const TypeInfo raspi4_machine_types[] = {
-#if HOST_LONG_BITS == 32
{
.name = MACHINE_TYPE_NAME("raspi4b-1g"),
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_1g_machine_class_init,
},
-#else
+#if HOST_LONG_BITS > 32
{
.name = MACHINE_TYPE_NAME("raspi4b-2g"),
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_2g_machine_class_init,
},
-#endif
+#endif /* HOST_LONG_BITS > 32 */
{
.name = TYPE_RASPI4_MACHINE,
.parent = TYPE_RASPI_BASE_MACHINE,
--
2.47.1
12:15 p.m.
New subject: [PATCH 6/7] hw/arm/raspi4b: Add the raspi4b-4g machine
Add the raspi4b-4g machine, a raspi4b rev1.4 with 4GB of RAM.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2797
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
hw/arm/raspi4b.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index 59b0d2ced44..2cf8bc467c5 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -133,6 +133,17 @@ static void raspi4b_2g_machine_class_init(ObjectClass *oc, void
*data)
mc->init = raspi4b_machine_init;
mc->alias = "raspi4b";
}
+
+static void raspi4b_4g_machine_class_init(ObjectClass *oc, void *data)
+{
+ MachineClass *mc = MACHINE_CLASS(oc);
+ RaspiBaseMachineClass *rmc = RASPI_BASE_MACHINE_CLASS(oc);
+
+
+ rmc->board_rev = 0xc03114; /* Revision 1.4, 4 GiB RAM */
+ raspi_machine_class_common_init(mc, rmc->board_rev);
+ mc->init = raspi4b_machine_init;
+}
#endif /* HOST_LONG_BITS > 32 */
static const TypeInfo raspi4_machine_types[] = {
@@ -147,6 +158,11 @@ static const TypeInfo raspi4_machine_types[] = {
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_2g_machine_class_init,
},
+ {
+ .name = MACHINE_TYPE_NAME("raspi4b-4g"),
+ .parent = TYPE_RASPI4_MACHINE,
+ .class_init = raspi4b_4g_machine_class_init,
+ },
#endif /* HOST_LONG_BITS > 32 */
{
.name = TYPE_RASPI4_MACHINE,
--
2.47.1
12:15 p.m.
New subject: [PATCH 7/7] hw/arm/raspi4b: Add the raspi4b-8g machine
Add the raspi4b-8g machine, a raspi4b rev1.5 with 8GB of RAM.
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
hw/arm/raspi4b.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c
index 2cf8bc467c5..2120bc1a6f8 100644
--- a/hw/arm/raspi4b.c
+++ b/hw/arm/raspi4b.c
@@ -144,6 +144,17 @@ static void raspi4b_4g_machine_class_init(ObjectClass *oc, void
*data)
raspi_machine_class_common_init(mc, rmc->board_rev);
mc->init = raspi4b_machine_init;
}
+
+static void raspi4b_8g_machine_class_init(ObjectClass *oc, void *data)
+{
+ MachineClass *mc = MACHINE_CLASS(oc);
+ RaspiBaseMachineClass *rmc = RASPI_BASE_MACHINE_CLASS(oc);
+
+
+ rmc->board_rev = 0xd03115; /* Revision 1.5, 8 GiB RAM */
+ raspi_machine_class_common_init(mc, rmc->board_rev);
+ mc->init = raspi4b_machine_init;
+}
#endif /* HOST_LONG_BITS > 32 */
static const TypeInfo raspi4_machine_types[] = {
@@ -163,6 +174,11 @@ static const TypeInfo raspi4_machine_types[] = {
.parent = TYPE_RASPI4_MACHINE,
.class_init = raspi4b_4g_machine_class_init,
},
+ {
+ .name = MACHINE_TYPE_NAME("raspi4b-8g"),
+ .parent = TYPE_RASPI4_MACHINE,
+ .class_init = raspi4b_8g_machine_class_init,
+ },
#endif /* HOST_LONG_BITS > 32 */
{
.name = TYPE_RASPI4_MACHINE,
--
2.47.1
3:57 p.m.
New subject: [PATCH 0/7] hw/arm/raspi4b: Add models with 4GB and 8GB of
DRAM
On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
- Deprecate the 'raspi4b' machine name, renaming it as
'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g' otherwise.
- Add the 'raspi4b-4g' and 'raspi4b-8g' machines, with
respectively 4GB and 8GB of DRAM.
IMHO (meaning you can ignore it, just my opinion) if the only difference
is the memory size -machine raspi4b -memory 4g would be better user
experience than having a lot of different machines. Or if you want to
emphasize these are tied to revisions maybe -machine raspi4b,revision=1.4
could be used. You can say that -machine help listing different versions
is easier to find but if it's the same machine with different options then
this should be a machine option, then you can use -machine raspi4b,help to
find the options specific to the machine. Memory size is normally set with
-memory so that could also select the revision as a convenience if this
is tied to a specific revision.
Regards,
BALATON Zoltan
Philippe Mathieu-Daudé (7):
hw/arm/raspi4b: Declare machine types using DEFINE_TYPES() macro
hw/arm/raspi4b: Introduce abstract raspi4-base machine type
hw/arm/raspi4b: Split raspi4b_machine_class_init() in two (1g and 2g)
hw/arm/raspi4b: Rename as raspi4b-1g / raspi4b-2g, deprecating old
name
hw/arm/raspi4b: Expose the raspi4b-1g machine on 64-bit hosts
hw/arm/raspi4b: Add the raspi4b-4g machine
hw/arm/raspi4b: Add the raspi4b-8g machine
docs/about/deprecated.rst | 6 +++
hw/arm/raspi4b.c | 91 +++++++++++++++++++++++++++++++--------
2 files changed, 79 insertions(+), 18 deletions(-)
4:51 p.m.
On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
> - Deprecate the 'raspi4b' machine name, renaming it as
> 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g' otherwise.
> - Add the 'raspi4b-4g' and 'raspi4b-8g' machines, with
> respectively 4GB and 8GB of DRAM.
IMHO (meaning you can ignore it, just my opinion) if the only difference
is the memory size -machine raspi4b -memory 4g would be better user
experience than having a lot of different machines.
Yes, I think I agree. We have a way for users to specify
how much memory they want, and I think it makes more sense
to use that than to have lots of different machine types.
thanks
-- PMM
5:29 p.m.
Peter Maydell <peter.maydell(a)linaro.org> writes:
On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
>
> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
> > - Deprecate the 'raspi4b' machine name, renaming it as
> > 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g' otherwise.
> > - Add the 'raspi4b-4g' and 'raspi4b-8g' machines, with
> > respectively 4GB and 8GB of DRAM.
>
> IMHO (meaning you can ignore it, just my opinion) if the only difference
> is the memory size -machine raspi4b -memory 4g would be better user
> experience than having a lot of different machines.
Yes, I think I agree. We have a way for users to specify
how much memory they want, and I think it makes more sense
to use that than to have lots of different machine types.
I guess for the Pi we should validate the -memory supplied is on of the
supported grid of devices rather than an arbitrary value?
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
5:33 p.m.
On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote:
Peter Maydell <peter.maydell(a)linaro.org> writes:
> On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
>>
>> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
>> > - Deprecate the 'raspi4b' machine name, renaming it as
>> > 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g' otherwise.
>> > - Add the 'raspi4b-4g' and 'raspi4b-8g' machines, with
>> > respectively 4GB and 8GB of DRAM.
>>
>> IMHO (meaning you can ignore it, just my opinion) if the only difference
>> is the memory size -machine raspi4b -memory 4g would be better user
>> experience than having a lot of different machines.
>
> Yes, I think I agree. We have a way for users to specify
> how much memory they want, and I think it makes more sense
> to use that than to have lots of different machine types.
I guess for the Pi we should validate the -memory supplied is on of the
supported grid of devices rather than an arbitrary value?
If the user wants to create a rpi4 with 6 GB RAM why should we stop
them ? It is their choice if they want to precisely replicate RAM
size from a physical model, or use something different when virtualized.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5:45 p.m.
On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote:
> Peter Maydell <peter.maydell(a)linaro.org> writes:
>
> > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
> >>
> >> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
> >> > - Deprecate the 'raspi4b' machine name, renaming it as
> >> > 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g'
otherwise.
> >> > - Add the 'raspi4b-4g' and 'raspi4b-8g' machines,
with
> >> > respectively 4GB and 8GB of DRAM.
> >>
> >> IMHO (meaning you can ignore it, just my opinion) if the only difference
> >> is the memory size -machine raspi4b -memory 4g would be better user
> >> experience than having a lot of different machines.
> >
> > Yes, I think I agree. We have a way for users to specify
> > how much memory they want, and I think it makes more sense
> > to use that than to have lots of different machine types.
>
> I guess for the Pi we should validate the -memory supplied is on of the
> supported grid of devices rather than an arbitrary value?
If the user wants to create a rpi4 with 6 GB RAM why should we stop
them ? It is their choice if they want to precisely replicate RAM
size from a physical model, or use something different when virtualized.
The board revision code (reported to the guest via the emulated
firmware interface) only supports reporting 256MB, 512MB,
1GB, 2GB, 4GB or 8GB:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#new...
For Arm embedded boards we mostly tend to "restrict the user
to what you can actually do", except for older boards where
we tended not to write any kind of sanity checking on CPU
type, memory size, etc.
thanks
-- PMM
5:50 p.m.
On Mon, Feb 03, 2025 at 02:45:06PM +0000, Peter Maydell wrote:
On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé
<berrange(a)redhat.com> wrote:
>
> On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote:
> > Peter Maydell <peter.maydell(a)linaro.org> writes:
> >
> > > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton(a)eik.bme.hu>
wrote:
> > >>
> > >> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
> > >> > - Deprecate the 'raspi4b' machine name, renaming it as
> > >> > 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g'
otherwise.
> > >> > - Add the 'raspi4b-4g' and 'raspi4b-8g' machines,
with
> > >> > respectively 4GB and 8GB of DRAM.
> > >>
> > >> IMHO (meaning you can ignore it, just my opinion) if the only
difference
> > >> is the memory size -machine raspi4b -memory 4g would be better user
> > >> experience than having a lot of different machines.
> > >
> > > Yes, I think I agree. We have a way for users to specify
> > > how much memory they want, and I think it makes more sense
> > > to use that than to have lots of different machine types.
> >
> > I guess for the Pi we should validate the -memory supplied is on of the
> > supported grid of devices rather than an arbitrary value?
>
> If the user wants to create a rpi4 with 6 GB RAM why should we stop
> them ? It is their choice if they want to precisely replicate RAM
> size from a physical model, or use something different when virtualized.
The board revision code (reported to the guest via the emulated
firmware interface) only supports reporting 256MB, 512MB,
1GB, 2GB, 4GB or 8GB:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#new...
I think it would be valid to report the revision code for the memory
size that doesn't exceed what QEMU has configured. eg if configured
with 6 GB, then report code for 4 GB.
For Arm embedded boards we mostly tend to "restrict the user
to what you can actually do", except for older boards where
we tended not to write any kind of sanity checking on CPU
type, memory size, etc.
If we're going to strictly limit memory size that's accepted I wonder
how we could information users/mgmt apps about what's permitted ?
Expressing valid combinations of configs across different args gets
pretty complicated quickly :-(
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:05 p.m.
On Mon, 3 Feb 2025 at 14:50, Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Mon, Feb 03, 2025 at 02:45:06PM +0000, Peter Maydell wrote:
> For Arm embedded boards we mostly tend to "restrict the user
> to what you can actually do", except for older boards where
> we tended not to write any kind of sanity checking on CPU
> type, memory size, etc.
If we're going to strictly limit memory size that's accepted I wonder
how we could information users/mgmt apps about what's permitted?
For users, we inform them by exiting with a hopefully informative
error message. Management apps presumably need to know already
because they would want to avoid presenting the guest with
weird configs that the guest OS might or might not cope with,
even if QEMU accepted them.
-- PMM
7:19 p.m.
On 3/2/25 15:50, Daniel P. Berrangé wrote:
On Mon, Feb 03, 2025 at 02:45:06PM +0000, Peter Maydell wrote:
> On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé <berrange(a)redhat.com> wrote:
>>
>> On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote:
>>> Peter Maydell <peter.maydell(a)linaro.org> writes:
>>>
>>>> On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton(a)eik.bme.hu>
wrote:
>>>>>
>>>>> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
>>>>>> - Deprecate the 'raspi4b' machine name, renaming it as
>>>>>> 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g'
otherwise.
>>>>>> - Add the 'raspi4b-4g' and 'raspi4b-8g' machines,
with
>>>>>> respectively 4GB and 8GB of DRAM.
>>>>>
>>>>> IMHO (meaning you can ignore it, just my opinion) if the only
difference
>>>>> is the memory size -machine raspi4b -memory 4g would be better user
>>>>> experience than having a lot of different machines.
>>>>
>>>> Yes, I think I agree. We have a way for users to specify
>>>> how much memory they want, and I think it makes more sense
>>>> to use that than to have lots of different machine types.
>>>
>>> I guess for the Pi we should validate the -memory supplied is on of the
>>> supported grid of devices rather than an arbitrary value?
>>
>> If the user wants to create a rpi4 with 6 GB RAM why should we stop
>> them ? It is their choice if they want to precisely replicate RAM
>> size from a physical model, or use something different when virtualized.
>
> The board revision code (reported to the guest via the emulated
> firmware interface) only supports reporting 256MB, 512MB,
> 1GB, 2GB, 4GB or 8GB:
>
>
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#new...
I think it would be valid to report the revision code for the memory
size that doesn't exceed what QEMU has configured. eg if configured
with 6 GB, then report code for 4 GB.
We need to distinct between physical machines VS virtual ones.
Guests on virtual machines have some way to figure the virtual
hardware (ACPI tables, DeviceTree blob, fw-cfg, ...).
Guests for physical machines usually expect fixed hardware (not
considering devices on busses).
For the particular case of the Raspberry Pi machines, their
bootloader gets the board layout by reading the
RPI_FWREQ_GET_BOARD_REVISION constant value.
What would be the point of emulating a raspi machine with 6GB
if the FW is not going to consider besides 4GB?
Besides, someone modify a guest to work with 6GB, it won't work
on real HW.
> For Arm embedded boards we mostly tend to "restrict the
user
> to what you can actually do", except for older boards where
> we tended not to write any kind of sanity checking on CPU
> type, memory size, etc.
If we're going to strictly limit memory size that's accepted I wonder
how we could information users/mgmt apps about what's permitted ?
Expressing valid combinations of configs across different args gets
pretty complicated quickly :-(
I'll try to address Zoltan and Peter request to have a dynamic raspi
machine. It is a bit unfortunate we didn't insisted on that when we
decided to expose a fixed set of existing boards in order to not be
bothered by inconsistent bug reports, back in 2019.
Regards,
Phil.
2:20 a.m.
New subject: [PATCH 0/7] hw/arm/raspi4b: Add models with 4GB and 8GB of
DRAM
On Mon, 3 Feb 2025, Philippe Mathieu-Daudé wrote:
On 3/2/25 15:50, Daniel P. Berrangé wrote:
> On Mon, Feb 03, 2025 at 02:45:06PM +0000, Peter Maydell wrote:
>> On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé <berrange(a)redhat.com>
>> wrote:
>>>
>>> On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote:
>>>> Peter Maydell <peter.maydell(a)linaro.org> writes:
>>>>
>>>>> On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
>>>>>>
>>>>>> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
>>>>>>> - Deprecate the 'raspi4b' machine name, renaming it
as
>>>>>>> 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g'
otherwise.
>>>>>>> - Add the 'raspi4b-4g' and 'raspi4b-8g'
machines, with
>>>>>>> respectively 4GB and 8GB of DRAM.
>>>>>>
>>>>>> IMHO (meaning you can ignore it, just my opinion) if the only
>>>>>> difference
>>>>>> is the memory size -machine raspi4b -memory 4g would be better
user
>>>>>> experience than having a lot of different machines.
>>>>>
>>>>> Yes, I think I agree. We have a way for users to specify
>>>>> how much memory they want, and I think it makes more sense
>>>>> to use that than to have lots of different machine types.
>>>>
>>>> I guess for the Pi we should validate the -memory supplied is on of the
>>>> supported grid of devices rather than an arbitrary value?
>>>
>>> If the user wants to create a rpi4 with 6 GB RAM why should we stop
>>> them ? It is their choice if they want to precisely replicate RAM
>>> size from a physical model, or use something different when virtualized.
>>
>> The board revision code (reported to the guest via the emulated
>> firmware interface) only supports reporting 256MB, 512MB,
>> 1GB, 2GB, 4GB or 8GB:
>>
>>
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#new...
>
> I think it would be valid to report the revision code for the memory
> size that doesn't exceed what QEMU has configured. eg if configured
> with 6 GB, then report code for 4 GB.
We need to distinct between physical machines VS virtual ones.
Guests on virtual machines have some way to figure the virtual
hardware (ACPI tables, DeviceTree blob, fw-cfg, ...).
Guests for physical machines usually expect fixed hardware (not
considering devices on busses).
For the particular case of the Raspberry Pi machines, their
bootloader gets the board layout by reading the
RPI_FWREQ_GET_BOARD_REVISION constant value.
What would be the point of emulating a raspi machine with 6GB
if the FW is not going to consider besides 4GB?
Besides, someone modify a guest to work with 6GB, it won't work
on real HW.
Usually the point of such non-standard configs would be running Linux via
-kernel which could use whatever is configured if it has a way to detect
it or maybe for memory it could even be specified on the kernel command
line. But maybe this is not a common enough config to support so reporting
error for memory size that's not on the list of valid sizes might be
enough. This is similar to qemu-system-ppc -machine sam460ex which has a
memory controller register that can only describe existing DIMM sizes.
Originally I allowed users to specify whatever memory size and only warn
for sizes not matching a DIMM size because Linux only looks at the device
tree which QEMU can generate when booting with -kernel so it works but the
firmware detects RAM from the SPD data and can only support certain sizes
so only less RAM that could be convered with SPD data would be visible for
guests. But then others thought it's better to return error for such cases
and changed it and removed the support for arbitrary memory size so now it
returns error when non power of 2 memory size is specified.
Regards,
BALATON Zoltan
>> For Arm embedded boards we mostly tend to "restrict the
user
>> to what you can actually do", except for older boards where
>> we tended not to write any kind of sanity checking on CPU
>> type, memory size, etc.
>
> If we're going to strictly limit memory size that's accepted I wonder
> how we could information users/mgmt apps about what's permitted ?
>
> Expressing valid combinations of configs across different args gets
> pretty complicated quickly :-(
I'll try to address Zoltan and Peter request to have a dynamic raspi
machine. It is a bit unfortunate we didn't insisted on that when we
decided to expose a fixed set of existing boards in order to not be
bothered by inconsistent bug reports, back in 2019.
Regards,
Phil.
2
days inactive
4
days old
17 comments
5 participants
participants (5)
-
Alex Bennée -
BALATON Zoltan -
Daniel P. Berrangé -
Peter Maydell -
Philippe Mathieu-Daudé