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

2020-06-30 Thread Philippe Mathieu-Daudé 
On 6/30/20 3:36 PM, Thomas Huth wrote:
> On 30/06/2020 13.17, Aleksandar Markovic wrote:
>>
>>
>> уторак, 30. јун 2020., Philippe Mathieu-Daudé > > је написао/ла:
>>
>>     On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
>>  >
>>  >
>>  > уторак, 30. јун 2020., Philippe Mathieu-Daudé >     
>>  > >> је написао/ла:
>>  >
>>  >     On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
>>  >     mailto:f4...@amsat.org>
>>     >> wrote:
>>  >     >
>>  >     > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
>>  >     > >
>>  >     > >
>>  >     > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
>>     mailto:f4...@amsat.org>
>>  >     >
>>  >     > > 
>>     >  >     > >
>>  >     > >     Hi,
>>  >     > >
>>  >     > >     Following Jiaxun Yang's patch and discussion:
>>  >     > > 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?
>>
>>
>> The answer is already in the original thread on the original patch.
>>
>> The problem is artificialy imposed:
>>
>> One needs a feature not present in the physical system. The solution
>> is not in creating "virtual" upgrade - this violates the basic
>> foundation if QEMU.
>>
>> If the feature is missing, the optimal solution would be emulating the
>> physical solution that has that feature.
>>

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

2020-06-30 Thread Thomas Huth 

On 30/06/2020 13.17, Aleksandar Markovic wrote:



уторак, 30. јун 2020., Philippe Mathieu-Daudé > је написао/ла:


On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
 >
 >
 > уторак, 30. јун 2020., Philippe Mathieu-Daudé mailto:f4...@amsat.org>
 > >> је написао/ла:
 >
 >     On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
 >     mailto:f4...@amsat.org>
>> wrote:
 >     >
 >     > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
 >     > >
 >     > >
 >     > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
mailto:f4...@amsat.org>
 >     >
 >     > > 
     > >
 >     > >     Hi,
 >     > >
 >     > >     Following Jiaxun Yang's patch and discussion:
 >     > > 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?


The answer is already in the original thread on the original patch.

The problem is artificialy imposed:

One needs a feature not present in the physical system. The solution is 
not in creating "virtual" upgrade - this violates the basic foundation 
if QEMU.


If the feature is missing, the optimal solution would be emulating the 
physical solution that has that feature.


In some rare cases (that should be avoided as mush as possible), and for 
really good reasons, we can create an emulation of some imagined 
hardware that was never designed let alone built - there are a couple of 
examples in other targets.


But extending the emulation of existing physical system with 
non-existing features is not acceptable.


Interesting statement. I suggest to include

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

2020-06-30 Thread Aleksandar Markovic 
уто, 30. јун 2020. у 13:59 Philippe Mathieu-Daudé  је
написао/ла:
>
> On 6/30/20 1:55 PM, Aleksandar Markovic wrote:
> > уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé  је
> > написао/ла:
> >>
> >> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
> >>> уторак, 30. јун 2020., Philippe Mathieu-Daudé  >>> > је написао/ла:
> >>>
> >>> On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> >>> >
> >>> >
> >>> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  >>> 
> >>> > >> је написао/ла:
> >>> >
> >>> > On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> >>> > mailto:f4...@amsat.org>
> >>> >> wrote:
> >>> > >
> >>> > > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >>> > > >
> >>> > > >
> >>> > > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
> >>> mailto:f4...@amsat.org>
> >>> > >
> >>> > > > 
> >>>  >>> > > >
> >>> > > > Hi,
> >>> > > >
> >>> > > > Following Jiaxun Yang's patch and discussion:
> >>> > > > 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?
> >>>
> >>>
> >>> The answer i

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

2020-06-30 Thread Philippe Mathieu-Daudé 
On 6/30/20 1:55 PM, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé  је
> написао/ла:
>>
>> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
>>> уторак, 30. јун 2020., Philippe Mathieu-Daudé >> > је написао/ла:
>>>
>>> On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
>>> >
>>> >
>>> > уторак, 30. јун 2020., Philippe Mathieu-Daudé >> 
>>> > >> је написао/ла:
>>> >
>>> > On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
>>> > mailto:f4...@amsat.org>
>>> >> wrote:
>>> > >
>>> > > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
>>> > > >
>>> > > >
>>> > > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
>>> mailto:f4...@amsat.org>
>>> > >
>>> > > > 
>>> >> > > >
>>> > > > Hi,
>>> > > >
>>> > > > Following Jiaxun Yang's patch and discussion:
>>> > > > 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?
>>>
>>>
>>> The answer is already in the original thread on the original patch.
>>>
>>> The problem is artificialy imposed:
>>>
>>> One needs a feature not present in the physical system. The solution is
>>> not in creating "virtual" upgrade - this violates the basic foundation
>>> if QEMU.
>>>
>>> If the feature is missing, the opt

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

2020-06-30 Thread Aleksandar Markovic 
уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé  је
написао/ла:
>
> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > > је написао/ла:
> >
> > On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > 
> > > >> је написао/ла:
> > >
> > > On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> > > mailto:f4...@amsat.org>
> > >> wrote:
> > > >
> > > > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > > > >
> > > > >
> > > > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
> > mailto:f4...@amsat.org>
> > > >
> > > > > 
> >  > > > >
> > > > > Hi,
> > > > >
> > > > > Following Jiaxun Yang's patch and discussion:
> > > > > 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?
> >
> >
> > The answer is already in the original thread on the original patch.
> >
> > The problem is artificialy imposed:
> >
> > One needs a feature not present in the physical system. The solution is
> > not in creating "virtual" upgrade - this violates the basic foundation
> > if QEMU.
> >
> > If the feature is missing, the optimal solution would be emulating the
> > physical sol

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

2020-06-30 Thread Philippe Mathieu-Daudé 
On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
> уторак, 30. јун 2020., Philippe Mathieu-Daudé  > је написао/ла:
> 
> On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  
> > >> је написао/ла:
> >
> >     On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> >     mailto:f4...@amsat.org>
> >> wrote:
> >     >
> >     > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >     > >
> >     > >
> >     > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
> mailto:f4...@amsat.org>
> >     >
> >     > > 
>  >     > >
> >     > >     Hi,
> >     > >
> >     > >     Following Jiaxun Yang's patch and discussion:
> >     > >     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?
> 
> 
> The answer is already in the original thread on the original patch.
> 
> The problem is artificialy imposed:
> 
> One needs a feature not present in the physical system. The solution is
> not in creating "virtual" upgrade - this violates the basic foundation
> if QEMU.
> 
> If the feature is missing, the optimal solution would be emulating the
> physical solution that has that feature.
> 
> In some rare cases (that should be avoided as mush as possible), and for
> really good reasons, we can create an emulation of some imagined
> hardware that was never designed let alone built - there are a couple of
> examples in other targets.
> 
> Bu

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

2020-06-30 Thread Aleksandar Markovic 
уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > > је написао/ла:
> >
> > On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> > mailto:f4...@amsat.org>> wrote:
> > >
> > > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > > >
> > > >
> > > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > 
> > > > >> је
> написао/ла:
> > > >
> > > > Hi,
> > > >
> > > > Following Jiaxun Yang's patch and discussion:
> > > > 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?
>
>
The answer is already in the original thread on the original patch.

The problem is artificialy imposed:

One needs a feature not present in the physical system. The solution is not
in creating "virtual" upgrade - this violates the basic foundation if QEMU.

If the feature is missing, the optimal solution would be emulating the
physical solution that has that feature.

In some rare cases (that should be avoided as mush as possible), and for
really good reasons, we can create an emulation of some imagined hardware
that was never designed let alone built - there are a couple of examples in
other targets.

But extending the emulation of existing physical system with non-existing
features is not acceptable.

Hopefuly everything is clear now to you. :)

Regards,
Aleksandar



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

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

2020-06-30 Thread Aleksandar Markovic 
уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/30/20 12:54 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > > је написао/ла:
> >
> > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > 
> > > >> је написао/ла:
> > >
> > > Hi,
> > >
> > > Following Jiaxun Yang's patch and discussion:
> > > 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).
> >
> >
> > Redo the series, and we can discuss, of course.
>
> I can resend without the last patch but I don't see the point,
> why not discuss first?
>
> QEMU should do its best to model a real Malta board. I don't
> want to break the current users for the existing 'malta' machine.
> How do you want me to name the real malta machine?
>
>
You now self-convinced yourself that only the last patch is wrong. I
repeat, the concept of the series is not ok, and, if you will, all patches
in the series are not good.

Regards,
Aleksandar


> >
> >
> > >
> > > 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
> > >
> > > Regards,
> > > Aleksandar
> > >
> > >
> > >
> > > 2.21.3
> > >
> >
>

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

2020-06-30 Thread Philippe Mathieu-Daudé 
On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> 
> 
> уторак, 30. јун 2020., Philippe Mathieu-Daudé  > је написао/ла:
> 
> On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> mailto:f4...@amsat.org>> wrote:
> >
> > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  
> > > >> је написао/ла:
> > >
> > >     Hi,
> > >
> > >     Following Jiaxun Yang's patch and discussion:
> > >     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
> > >
>

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

2020-06-30 Thread Aleksandar Markovic 
уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé 
> wrote:
> >
> > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > > > је написао/ла:
> > >
> > > Hi,
> > >
> > > Following Jiaxun Yang's patch and discussion:
> > > 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.

Regards,
Aleksandar







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

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

2020-06-30 Thread Philippe Mathieu-Daudé 
On 6/30/20 12:54 PM, Aleksandar Markovic wrote:
> 
> 
> уторак, 30. јун 2020., Philippe Mathieu-Daudé  > је написао/ла:
> 
> On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  
> > >> је написао/ла:
> >
> >     Hi,
> >
> >     Following Jiaxun Yang's patch and discussion:
> >     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).
> 
> 
> Redo the series, and we can discuss, of course.

I can resend without the last patch but I don't see the point,
why not discuss first?

QEMU should do its best to model a real Malta board. I don't
want to break the current users for the existing 'malta' machine.
How do you want me to name the real malta machine?

>  
> 
> >
> > 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 
> >
> > Regards,
> > Aleksandar
> >
> >  
> >
> >     2.21.3
> >
>

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

2020-06-30 Thread Aleksandar Markovic 
уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > > је написао/ла:
> >
> > Hi,
> >
> > Following Jiaxun Yang's patch and discussion:
> > 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).
>
>
Redo the series, and we can discuss, of course.


> >
> > 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
> >
> > Regards,
> > Aleksandar
> >
> >
> >
> > 2.21.3
> >
>

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

2020-06-30 Thread Philippe Mathieu-Daudé 
On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé  wrote:
>
> On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > > је написао/ла:
> >
> > Hi,
> >
> > Following Jiaxun Yang's patch and discussion:
> > 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?

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

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

2020-06-30 Thread Philippe Mathieu-Daudé 
On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> 
> 
> уторак, 30. јун 2020., Philippe Mathieu-Daudé  > је написао/ла:
> 
> Hi,
> 
> Following Jiaxun Yang's patch and discussion:
> 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 
> 
> Regards,
> Aleksandar
> 
>  
> 
> 2.21.3
>

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

2020-06-30 Thread Aleksandar Markovic 
уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> Hi,
>
> Following Jiaxun Yang's patch and discussion:
> 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.

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

Regards,
Aleksandar



> 2.21.3
>
>