On Tue, 7 Jan 2020 12:53:32 +0100 Helge Deller <del...@gmx.de> 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/qemu-devel@nongnu.org/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 [...]
