| Message ID | 20250201091528.1177-1-philmd@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/arm/raspi4b: Add models with 4GB and 8GB of DRAM | expand |
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(-) > >
On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@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
Peter Maydell <peter.maydell@linaro.org> writes: > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@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?
On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > > > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@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
On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote: > > Peter Maydell <peter.maydell@linaro.org> writes: > > > > > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@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-style-revision-codes 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
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@redhat.com> wrote: > > > > On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote: > > > Peter Maydell <peter.maydell@linaro.org> writes: > > > > > > > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@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-style-revision-codes 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
On Mon, 3 Feb 2025 at 14:50, Daniel P. Berrangé <berrange@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
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@redhat.com> wrote: >>> >>> On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote: >>>> Peter Maydell <peter.maydell@linaro.org> writes: >>>> >>>>> On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@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-style-revision-codes > > 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.
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@redhat.com> >>> wrote: >>>> >>>> On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote: >>>>> Peter Maydell <peter.maydell@linaro.org> writes: >>>>> >>>>>> On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@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-style-revision-codes >> >> 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. > >
- 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(-)