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@xxxxxxxxxx> wrote:
On Mon, Feb 03, 2025 at 02:29:49PM +0000, Alex Bennée wrote:
Peter Maydell <peter.maydell@xxxxxxxxxx> writes:
On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan <balaton@xxxxxxxxxx> 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.
