Re: [PATCH v2] hppa: allow max ram size upto 4Gb

[Igor Mammedov]

On Tue, 7 Jan 2020 12:53:32 +0100
Helge Deller <address@hidden> wrote:

Even though I disagree and it would waste ~256Mb 4Gb of RAM,
I think I should be able to replace #43 with
  "hppa: allow max ram size upto 4Gb"
as it still removes fix up at mapped address space level,
removes fix up of global ram_size variable and adds max size check,

which lets hppa board get out of the way of re-factoring
generic RAM allocation and making what board does with
provided RAM its own business.

> On 07.01.20 12:21, Igor Mammedov wrote:
> > On Mon, 6 Jan 2020 18:03:49 +0100  
> >> So, I'd suggest to drop your wrong patch #43.  
> > As you noted in your first reply, patch is correct.  
> 
> You probably got me wrong.
whichever way I read it
https://www.mail-archive.com/address@hidden/msg667855.html
states user convenience as a reason.

> Your patch #43 is wrong, and your fixup patch to some degree reverts it back 
> again.
>
> 
> In patch #43 you error out and stop, which real hardware wouldn't do.
> Real hardware simply ignores the memory which wouldn't be used.
> > All it's doing is validating user input versus RAM size
> > actually supported by the current code, telling user> current supported 
> > limit and enforcing it.  
> 
> Real hardware would not tell user.
>
> > I agree it's inconvenience for the users since they
> > won't be able to specify non-sense values and still
> > get board running, but that's clear user error and
> > should be corrected on user side and not by QEMU
> > magically masking wrong CLI values.  
> 
> I disagree.
> Everything worked as expected before, but with *your* change now people
> might need to modify their CLI.
> 4GB is a valid amount of memory which can be plugged into
> the virtual and physical machine.
> It's not magic, it's how the architecture works and you changed it.
>
> > Since it could be fixed on user side, I care less
> > about user convenience when it comes to correctness
> > and unified code.  
> 
> IMHO, you should care about that the emulation works the same
> way as physical machine. 

As for correctness wrt real hardware questions are:
 * is one able to stuff hardware with unsupported 4Gb or more DIMMs,
   will system even work?
 * what real hardware does with top 256Gb of 4Gb RAM if present?
   Is it addressable/accessible in some way by CPUs or devices?
 * how does real firmware discovers amount of installed RAM

[...]