On Thu, 2 Jan 2020 14:02:01 +0100
Helge Deller <del...@gmx.de> wrote:
> On 02.01.20 13:06, Philippe Mathieu-Daudé wrote:
> > On 1/2/20 12:31 PM, Helge Deller wrote:
> >> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >>>> If user provided non-sense RAM size, board will complain and
> >>>> continue running with max RAM size supported.
> >>>> Also RAM is going to be allocated by generic code, so it won't be
> >>>> possible for board to fix things up for user.
> >>>>
> >>>> Make it error message and exit to force user fix CLI,
> >>>> instead of accepting non-sense CLI values.
> >>>>
> >>>> Signed-off-by: Igor Mammedov <imamm...@redhat.com>
> >>>> ---
> >>>> hw/hppa/machine.c | 3 ++-
> >>>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> >>>> index 5d0de26..25f5afc 100644
> >>>> --- a/hw/hppa/machine.c
> >>>> +++ b/hw/hppa/machine.c
> >>>> @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
> >>>> /* Limit main memory. */
> >>>> if (ram_size > FIRMWARE_START) {
> >>>> - machine->ram_size = ram_size = FIRMWARE_START;
> >>>> + error_report("RAM size more than %d is not supported",
> >>>> FIRMWARE_START);
> >>>> + exit(EXIT_FAILURE);
> >>>
> >>> $ qemu-system-hppa -m 3841m
> >>> qemu-system-hppa: invalid accelerator kvm
> >>> qemu-system-hppa: falling back to tcg
> >>> qemu-system-hppa: RAM size more than -268435456 is not supported
> >>>
> >>> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format,
> >>> we can simply use "RAM size more than 3840m is not supported". Is that OK
> >>> with you?
> >>
> >> I don't really like that change.
> >>
> >> We currently only emulate a 32-bit system, and for those 4GB is the
> >> maximum.
> >> So, if I start my machine with "qemu-system-hppa -m 4G", the current code
> >> then automatically uses the maximum possible of 3841MB (which is limited by
> >> firmware start address).
> >> I don't expect users to know the excact 3841MB number.
> >> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
> >> but not "3841MB".
> >
> > Thanks for the explanation. This deserves a comment in the source
> > file IMHO (and displaying a warning to the user that the behavior is
> > changed).
>
> If you put 4GB physically in the box, you wouldn't get a warning either...
> It will simply use just 3841MB.
>
> > I understand the CPU can't access this DRAM area because the ROM is
> > mapped there. What about other devices, can they do DMA access to
> > it?
>
> Yes, I think so.
Question is if is it supported/used in current impl?
If it's not then lets keep a hard error providing the exact max value,
instead of complicating code for unclear benefit.
>
> > Igor: If this complicates your series too much, I think we can
> > directly allocate up-to 4GiB and not worry about the 256MiB lost.
>
> Sounds like the best solution.
>
> Helge
>
