Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Philippe Mathieu-Daudé]

On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> 
> 
> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> <mailto:f4bug@amsat.org>> је написао/ла:
> 
>     On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
>     <f4bug@amsat.org <mailto:f4bug@amsat.org>> wrote:
>     >
>     > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
>     > >
>     > >
>     > > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
>     <mailto:f4bug@amsat.org>
>     > > <mailto:f4bug@amsat.org <mailto:f4bug@amsat.org>>> је написао/ла:
>     > >
>     > >     Hi,
>     > >
>     > >     Following Jiaxun Yang's patch and discussion:
>     > >     https://patchwork.kernel.org/patch/11416915/
>     <https://patchwork.kernel.org/patch/11416915/>
>     > >     <https://patchwork.kernel.org/patch/11416915/
>     <https://patchwork.kernel.org/patch/11416915/>>
>     > >
>     > >     - Rename the current machine as 'malta-virt' (keeping
>     'malta' aliased)
>     > >       Suggestions for better names are welcome, maybe
>     'malta-unreal' or
>     > >       'malta-unleashed' instead?
>     > >     - Add 'malta-phys' which respects hardware restrictions (on
>     RAM so far)
>     > >     - Unleash 'malta-virt' to allow more than 2GB on 64-bit
>     > >
>     > >     Philippe Mathieu-Daudé (7):
>     > >       hw/mips/malta: Trivial code movement
>     > >       hw/mips/malta: Register the machine as a TypeInfo
>     > >       hw/mips/malta: Rename 'malta' machine as 'malta-virt'
>     > >       hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>     > >       hw/mips/malta: Introduce the 'malta-phys' machine
>     > >       hw/mips/malta: Verify malta-phys machine uses correct DIMM
>     sizes
>     > >       hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
>     > >
>     > >      hw/mips/malta.c | 121
>     +++++++++++++++++++++++++++++++++++++++---------
>     > >      1 file changed, 99 insertions(+), 22 deletions(-)
>     > >
>     > >     --
>     > >
>     > >
>     > >
>     > > Thank you, Philippe, for providing this series.
>     > >
>     > > However, in previous discussion on the patch you mention above, I
>     > > already expressed serious reservations on the approach taken in that
>     > > patch. These reservations stay today too.
>     > >
>     > > There is nothing qualitatively different between the original
>     patch and
>     > > this series. Naming and related stuff are just cosmetic issues.
>     >
>     > OK, what about considering all patches except the last one?
>     > So we can run firmware on a real Malta board, not the QEMU
>     > imaginary one (in the discussion you said QEMU should respect
>     > real hardware, which I agree).
>     >
>     > >
>     > > The good thing about this series is that one can apply it
>     dowstream, if
>     > > one finds it useful. However, it is not suitable for upstreaming
> 
>     IOW, what is missing to have this series (except the last patch)
>     accepted upstream?
> 
> 
> It is not what is missing, but was already is in the series that makes
> it not suitable for upstreaming. The very concept of the series is
> problematic.

What is the series is not suitable for upstream? Can you point to
patch and code please? How would you conceptually resolve the
problem?

> 
> Regards,
> Aleksandar
> 
> 
> 
> 
> 
>  
> 
>     > >
>     > > Regards,
>     > > Aleksandar
>     > >
>     > >
>     > >
>     > >     2.21.3
>     > >
>