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

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

[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(-)

-- 
2.21.3

[PATCH 1/7] hw/mips/malta: Trivial code movement

[Philippe Mathieu-Daudé]

Trivial code movement to make the next patch easier to review.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/mips/malta.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index d95926a89c..5b371c1e34 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1426,6 +1426,13 @@ static const TypeInfo mips_malta_device = {
     .instance_size = sizeof(MaltaState),
 };
 
+static void mips_malta_register_types(void)
+{
+    type_register_static(&mips_malta_device);
+}
+
+type_init(mips_malta_register_types)
+
 static void mips_malta_machine_init(MachineClass *mc)
 {
     mc->desc = "MIPS Malta Core LV";
@@ -1442,10 +1449,3 @@ static void mips_malta_machine_init(MachineClass *mc)
 }
 
 DEFINE_MACHINE("malta", mips_malta_machine_init)
-
-static void mips_malta_register_types(void)
-{
-    type_register_static(&mips_malta_device);
-}
-
-type_init(mips_malta_register_types)
-- 
2.21.3

[PATCH 2/7] hw/mips/malta: Register the machine as a TypeInfo

[Philippe Mathieu-Daudé]

We want to add more machines. First convert from the old
DEFINE_MACHINE() API to the more recent DEFINE_TYPES(TypeInfo[])
one.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/mips/malta.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 5b371c1e34..66172f0c82 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -70,6 +70,8 @@
 
 #define MAX_IDE_BUS         2
 
+#define TYPE_MALTA_MACHINE       MACHINE_TYPE_NAME("malta")
+
 typedef struct {
     MemoryRegion iomem;
     MemoryRegion iomem_lo; /* 0 - 0x900 */
@@ -1433,8 +1435,10 @@ static void mips_malta_register_types(void)
 
 type_init(mips_malta_register_types)
 
-static void mips_malta_machine_init(MachineClass *mc)
+static void malta_machine_class_init(ObjectClass *oc, void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "MIPS Malta Core LV";
     mc->init = mips_malta_init;
     mc->block_default_type = IF_IDE;
@@ -1448,4 +1452,16 @@ static void mips_malta_machine_init(MachineClass *mc)
     mc->default_ram_id = "mips_malta.ram";
 }
 
-DEFINE_MACHINE("malta", mips_malta_machine_init)
+static const TypeInfo malta_machine_types[] = {
+    {
+        .name          = MACHINE_TYPE_NAME("malta"),
+        .parent        = TYPE_MALTA_MACHINE,
+    }, {
+        .name          = TYPE_MALTA_MACHINE,
+        .parent        = TYPE_MACHINE,
+        .class_init    = malta_machine_class_init,
+        .abstract      = true,
+    }
+};
+
+DEFINE_TYPES(malta_machine_types)
-- 
2.21.3

[PATCH 3/7] hw/mips/malta: Rename 'malta' machine as 'malta-virt'

[Philippe Mathieu-Daudé]

We want to model the real physical Malta board. The current model
does not have the physical restrictions real hardware have.
Rename the current machine as 'malta-virt'. To not disrupt command
line users, keep the 'malta' machine name as an alias.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/mips/malta.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 66172f0c82..f8fc567532 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1439,8 +1439,16 @@ static void malta_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
 
-    mc->desc = "MIPS Malta Core LV";
     mc->init = mips_malta_init;
+    mc->default_ram_id = "mips_malta.ram";
+}
+
+static void malta_machine_virt_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    mc->desc = "MIPS Malta Core LV (no physical limitations)";
+    mc->alias = "malta";
     mc->block_default_type = IF_IDE;
     mc->max_cpus = 16;
     mc->is_default = true;
@@ -1449,13 +1457,13 @@ static void malta_machine_class_init(ObjectClass *oc, void *data)
 #else
     mc->default_cpu_type = MIPS_CPU_TYPE_NAME("24Kf");
 #endif
-    mc->default_ram_id = "mips_malta.ram";
 }
 
 static const TypeInfo malta_machine_types[] = {
     {
-        .name          = MACHINE_TYPE_NAME("malta"),
+        .name          = MACHINE_TYPE_NAME("malta-virt"),
         .parent        = TYPE_MALTA_MACHINE,
+        .class_init    = malta_machine_virt_class_init,
     }, {
         .name          = TYPE_MALTA_MACHINE,
         .parent        = TYPE_MACHINE,
-- 
2.21.3

[PATCH 4/7] hw/mips/malta: Introduce MaltaMachineClass::max_ramsize

[Philippe Mathieu-Daudé]

The maximum RAM size is tied to the machine. First add the
MaltaMachineClass, and add 'max_ramsize' to it. Set it to
the current value of 2 GB, and adapt the code checking for
the requested RAM is usable by the machine.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/mips/malta.c | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index f8fc567532..1ca41b44db 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -56,6 +56,7 @@
 #include "sysemu/kvm.h"
 #include "hw/semihosting/semihost.h"
 #include "hw/mips/cps.h"
+#include "qemu/cutils.h"
 
 #define ENVP_ADDR           0x80002000l
 #define ENVP_NB_ENTRIES     16
@@ -71,6 +72,17 @@
 #define MAX_IDE_BUS         2
 
 #define TYPE_MALTA_MACHINE       MACHINE_TYPE_NAME("malta")
+#define MALTA_MACHINE_CLASS(klass) \
+     OBJECT_CLASS_CHECK(MaltaMachineClass, (klass), TYPE_MALTA_MACHINE)
+#define MALTA_MACHINE_GET_CLASS(obj) \
+     OBJECT_GET_CLASS(MaltaMachineClass, (obj), TYPE_MALTA_MACHINE)
+
+typedef struct MaltaMachineClass {
+    /* Private */
+    MachineClass parent_obj;
+    /* Public */
+    ram_addr_t max_ramsize;
+} MaltaMachineClass;
 
 typedef struct {
     MemoryRegion iomem;
@@ -1232,7 +1244,7 @@ void mips_malta_init(MachineState *machine)
     DriveInfo *dinfo;
     int fl_idx = 0;
     int be;
-
+    MaltaMachineClass *mmc = MALTA_MACHINE_GET_CLASS(machine);
     DeviceState *dev = qdev_new(TYPE_MIPS_MALTA);
     MaltaState *s = MIPS_MALTA(dev);
 
@@ -1248,10 +1260,16 @@ void mips_malta_init(MachineState *machine)
     /* create CPU */
     mips_create_cpu(machine, s, &cbus_irq, &i8259_irq);
 
-    /* allocate RAM */
-    if (ram_size > 2 * GiB) {
-        error_report("Too much memory for this machine: %" PRId64 "MB,"
-                     " maximum 2048MB", ram_size / MiB);
+    /*
+     * The GT-64120A north bridge accepts at most 256 MiB per SCS for
+     * address decoding, so we have a maximum of 1 GiB. We deliberately
+     * ignore this physical limitation.
+     */
+    if (ram_size > mmc->max_ramsize) {
+        char *maxsize_str = size_to_str(mmc->max_ramsize);
+        error_report("Too much memory for this machine: %" PRId64 " MiB,"
+                     " maximum %s", ram_size / MiB, maxsize_str);
+        g_free(maxsize_str);
         exit(1);
     }
 
@@ -1446,6 +1464,7 @@ static void malta_machine_class_init(ObjectClass *oc, void *data)
 static void malta_machine_virt_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
+    MaltaMachineClass *mmc = MALTA_MACHINE_CLASS(oc);
 
     mc->desc = "MIPS Malta Core LV (no physical limitations)";
     mc->alias = "malta";
@@ -1457,6 +1476,7 @@ static void malta_machine_virt_class_init(ObjectClass *oc, void *data)
 #else
     mc->default_cpu_type = MIPS_CPU_TYPE_NAME("24Kf");
 #endif
+    mmc->max_ramsize = 2 * GiB;
 }
 
 static const TypeInfo malta_machine_types[] = {
@@ -1467,6 +1487,7 @@ static const TypeInfo malta_machine_types[] = {
     }, {
         .name          = TYPE_MALTA_MACHINE,
         .parent        = TYPE_MACHINE,
+        .class_size    = sizeof(MaltaMachineClass),
         .class_init    = malta_machine_class_init,
         .abstract      = true,
     }
-- 
2.21.3

[PATCH 5/7] hw/mips/malta: Introduce the 'malta-phys' machine

[Philippe Mathieu-Daudé]

Introduce the 'malta-phys' machine, aiming to have the same
limitations as real hardware. Start by restricting the RAM
to 1GB, which is the maximum amount of memory the GT-64120A
north bridge can address.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/mips/malta.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 1ca41b44db..013bf9272c 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1479,11 +1479,32 @@ static void malta_machine_virt_class_init(ObjectClass *oc, void *data)
     mmc->max_ramsize = 2 * GiB;
 }
 
+static void malta_machine_phys_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+    MaltaMachineClass *mmc = MALTA_MACHINE_CLASS(oc);
+
+    mc->desc = "MIPS Malta Core LV (physically limited as real hardware)";
+    mc->block_default_type = IF_PFLASH;
+    mc->max_cpus = 1;
+#ifdef TARGET_MIPS64
+    mc->default_cpu_type = MIPS_CPU_TYPE_NAME("5Kc");
+#else
+    mc->default_cpu_type = MIPS_CPU_TYPE_NAME("4Kc");
+#endif
+    mc->default_ram_size = 32 * MiB;
+    mmc->max_ramsize = 256 * MiB; /* 32 MByte PC100 SDRAM DIMMs x 4 slots */
+};
+
 static const TypeInfo malta_machine_types[] = {
     {
         .name          = MACHINE_TYPE_NAME("malta-virt"),
         .parent        = TYPE_MALTA_MACHINE,
         .class_init    = malta_machine_virt_class_init,
+    }, {
+        .name          = MACHINE_TYPE_NAME("malta-phys"),
+        .parent        = TYPE_MALTA_MACHINE,
+        .class_init    = malta_machine_phys_class_init,
     }, {
         .name          = TYPE_MALTA_MACHINE,
         .parent        = TYPE_MACHINE,
-- 
2.21.3

Re: [PATCH 5/7] hw/mips/malta: Introduce the 'malta-phys' machine

[Philippe Mathieu-Daudé]

On 6/30/20 10:13 AM, Philippe Mathieu-Daudé wrote:
> Introduce the 'malta-phys' machine, aiming to have the same
> limitations as real hardware. Start by restricting the RAM
> to 1GB, which is the maximum amount of memory the GT-64120A
> north bridge can address.

Oops wrong comment, it ended mixed from previous patch while
rebasing. Corrected:

"Start with 32 MB which is the default on the CoreLV, and
allow up to 256 MB which is the maximum this card can
accept. See MIPS Document Number: MD00051 Revision 01.07"

> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/mips/malta.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/hw/mips/malta.c b/hw/mips/malta.c
> index 1ca41b44db..013bf9272c 100644
> --- a/hw/mips/malta.c
> +++ b/hw/mips/malta.c
> @@ -1479,11 +1479,32 @@ static void malta_machine_virt_class_init(ObjectClass *oc, void *data)
>      mmc->max_ramsize = 2 * GiB;
>  }
>  
> +static void malta_machine_phys_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +    MaltaMachineClass *mmc = MALTA_MACHINE_CLASS(oc);
> +
> +    mc->desc = "MIPS Malta Core LV (physically limited as real hardware)";
> +    mc->block_default_type = IF_PFLASH;
> +    mc->max_cpus = 1;
> +#ifdef TARGET_MIPS64
> +    mc->default_cpu_type = MIPS_CPU_TYPE_NAME("5Kc");
> +#else
> +    mc->default_cpu_type = MIPS_CPU_TYPE_NAME("4Kc");
> +#endif
> +    mc->default_ram_size = 32 * MiB;
> +    mmc->max_ramsize = 256 * MiB; /* 32 MByte PC100 SDRAM DIMMs x 4 slots */
> +};
> +
>  static const TypeInfo malta_machine_types[] = {
>      {
>          .name          = MACHINE_TYPE_NAME("malta-virt"),
>          .parent        = TYPE_MALTA_MACHINE,
>          .class_init    = malta_machine_virt_class_init,
> +    }, {
> +        .name          = MACHINE_TYPE_NAME("malta-phys"),
> +        .parent        = TYPE_MALTA_MACHINE,
> +        .class_init    = malta_machine_phys_class_init,
>      }, {
>          .name          = TYPE_MALTA_MACHINE,
>          .parent        = TYPE_MACHINE,
> 

[PATCH 6/7] hw/mips/malta: Verify malta-phys machine uses correct DIMM sizes

[Philippe Mathieu-Daudé]

The machine has 4 DIMM slots. Each DIMM must be a power of 2.
Add a check the total RAM is a good combination of DIMMs.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/mips/malta.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 013bf9272c..5768b88183 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -71,6 +71,8 @@
 
 #define MAX_IDE_BUS         2
 
+#define DIMM_SLOTS_COUNT    4
+
 #define TYPE_MALTA_MACHINE       MACHINE_TYPE_NAME("malta")
 #define MALTA_MACHINE_CLASS(klass) \
      OBJECT_CLASS_CHECK(MaltaMachineClass, (klass), TYPE_MALTA_MACHINE)
@@ -82,6 +84,7 @@ typedef struct MaltaMachineClass {
     MachineClass parent_obj;
     /* Public */
     ram_addr_t max_ramsize;
+    bool verify_dimm_sizes;
 } MaltaMachineClass;
 
 typedef struct {
@@ -1260,6 +1263,12 @@ void mips_malta_init(MachineState *machine)
     /* create CPU */
     mips_create_cpu(machine, s, &cbus_irq, &i8259_irq);
 
+    if (mmc->verify_dimm_sizes && ctpop64(ram_size) > DIMM_SLOTS_COUNT) {
+        error_report("RAM size must be the combination of %d powers of 2",
+                     DIMM_SLOTS_COUNT);
+        exit(1);
+    }
+
     /*
      * The GT-64120A north bridge accepts at most 256 MiB per SCS for
      * address decoding, so we have a maximum of 1 GiB. We deliberately
@@ -1494,6 +1503,7 @@ static void malta_machine_phys_class_init(ObjectClass *oc, void *data)
 #endif
     mc->default_ram_size = 32 * MiB;
     mmc->max_ramsize = 256 * MiB; /* 32 MByte PC100 SDRAM DIMMs x 4 slots */
+    mmc->verify_dimm_sizes = true;
 };
 
 static const TypeInfo malta_machine_types[] = {
-- 
2.21.3

[PATCH 7/7] hw/mips/malta: Allow more than 2GB on 64-bit malta-virt

[Philippe Mathieu-Daudé]

Since we don't respect the hardware restrictions, there is no good
reason to limit the maximum amount of RAM to 2GB.

Suggested-by: Yunqiang Su <ysu@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/mips/malta.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 5768b88183..277cbc0303 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1482,10 +1482,11 @@ static void malta_machine_virt_class_init(ObjectClass *oc, void *data)
     mc->is_default = true;
 #ifdef TARGET_MIPS64
     mc->default_cpu_type = MIPS_CPU_TYPE_NAME("20Kc");
+    mmc->max_ramsize = 3 * GiB;
 #else
     mc->default_cpu_type = MIPS_CPU_TYPE_NAME("24Kf");
-#endif
     mmc->max_ramsize = 2 * GiB;
+#endif
 }
 
 static void malta_machine_phys_class_init(ObjectClass *oc, void *data)
-- 
2.21.3

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

[Aleksandar Markovic]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@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.

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
>
>

[-- Attachment #2: Type: text/html, Size: 2328 bytes --]

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 12:48 PM, Aleksandar Markovic wrote:
> 
> 
> уторак, 30. јун 2020., Philippe Mathieu-Daudé <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/>
> 
>     - 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

[Philippe Mathieu-Daudé]

On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé <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>> је написао/ла:
> >
> >     Hi,
> >
> >     Following Jiaxun Yang's patch and discussion:
> >     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?

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

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

[Aleksandar Markovic]

[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]

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

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

Regards,
Aleksandar







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

[-- Attachment #2: Type: text/html, Size: 4175 bytes --]

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
>     > >
> 

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

[Aleksandar Markovic]

[-- Attachment #1: Type: text/plain, Size: 4725 bytes --]

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

> 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?
>
>
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
> >     > >
> >
>

[-- Attachment #2: Type: text/html, Size: 7112 bytes --]

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:17 PM, Aleksandar Markovic wrote:
> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> <mailto:f4bug@amsat.org>> је написао/ла:
> 
>     On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
>     >
>     >
>     > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
>     <mailto:f4bug@amsat.org>
>     > <mailto: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>
>     <mailto: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>>
>     >     > > <mailto: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/>>
>     >     > >     <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?
> 
> 
> 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. :)

I guess I understand a bit. I was confused by your use of "upstream".
It seems you use it the wrong way, so for you "upstream" is what the
MIPS enterprise world wants/needs, while "downstream" is what the
open-source community wants/needs.

If MIPS enterprise doesn't want a Malta machine model with 3GB of RAM,
they can disable it in their downstream.
If it helps the upstream community, the model is wrong anyway by using
2GB. It would be disastrous for all user to restrict the malta machine
to 1GB upstream.

> 
> 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

[Aleksandar Markovic]

уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé <f4bug@amsat.org> је
написао/ла:
>
> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> > <mailto:f4bug@amsat.org>> је написао/ла:
> >
> >     On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> >     >
> >     >
> >     > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> >     <mailto:f4bug@amsat.org>
> >     > <mailto: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>
> >     <mailto: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>>
> >     >     > > <mailto: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/>>
> >     >     > >     <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?
> >
> >
> > 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. :)
>
> I guess I understand a bit. I was confused by your use of "upstream".
> It seems you use it the wrong way, so for you "upstream" is what the
> MIPS enterprise world wants/needs, while "downstream" is what the
> open-source community wants/needs.
>
> If MIPS enterprise doesn't want a Malta machine model with 3GB of RAM,
> they can disable it in their downstream.
> If it helps the upstream community, the model is wrong anyway by using
> 2GB. It would be disastrous for all user to restrict the malta machine
> to 1GB upstream.
>

No, when I said "upstream" I meant what "upstream" always meant - our
central QEMU repository.

There is no different treatment of proposals whatever or whoever is
the origin of the proposal. The proposals are judged only on their
technical merits.

It is very difficult to cooperate with you if you constantly put in my
mouth what I would never say, like you did more than once in this
thread.

Regards,
Aleksandar

> >
> > 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

[Philippe Mathieu-Daudé]

On 6/30/20 1:55 PM, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> написао/ла:
>>
>> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
>>> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
>>> <mailto:f4bug@amsat.org>> је написао/ла:
>>>
>>>     On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
>>>     >
>>>     >
>>>     > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
>>>     <mailto:f4bug@amsat.org>
>>>     > <mailto: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>
>>>     <mailto: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>>
>>>     >     > > <mailto: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/>>
>>>     >     > >     <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?
>>>
>>>
>>> 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. :)
>>
>> I guess I understand a bit. I was confused by your use of "upstream".
>> It seems you use it the wrong way, so for you "upstream" is what the
>> MIPS enterprise world wants/needs, while "downstream" is what the
>> open-source community wants/needs.
>>
>> If MIPS enterprise doesn't want a Malta machine model with 3GB of RAM,
>> they can disable it in their downstream.
>> If it helps the upstream community, the model is wrong anyway by using
>> 2GB. It would be disastrous for all user to restrict the malta machine
>> to 1GB upstream.
>>
> 
> No, when I said "upstream" I meant what "upstream" always meant - our
> central QEMU repository.
> 
> There is no different treatment of proposals whatever or whoever is
> the origin of the proposal. The proposals are judged only on their
> technical merits.
> 
> It is very difficult to cooperate with you if you constantly put in my
> mouth what I would never say, like you did more than once in this
> thread.

That would help if you answer all questions (so I don't have to guess)
and explain why you decide to say "no", so I don't have to ask you
for details.

So I don't understand why you treat "upstream" as only owned by MIPS
enterprise. Aurelien put me here to represent the hobbyist users.
You can not simply say "no", we have to discuss and get a consensus
for the best of all the community, not only your company/employer.
This is not always easy, but this is open source, you have to work
in the open with other contributors, and can not only dictate.

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

[Aleksandar Markovic]

уто, 30. јун 2020. у 13:59 Philippe Mathieu-Daudé <f4bug@amsat.org> је
написао/ла:
>
> On 6/30/20 1:55 PM, Aleksandar Markovic wrote:
> > уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> > написао/ла:
> >>
> >> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
> >>> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> >>> <mailto:f4bug@amsat.org>> је написао/ла:
> >>>
> >>>     On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> >>>     >
> >>>     >
> >>>     > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> >>>     <mailto:f4bug@amsat.org>
> >>>     > <mailto: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>
> >>>     <mailto: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>>
> >>>     >     > > <mailto: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/>>
> >>>     >     > >     <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?
> >>>
> >>>
> >>> 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. :)
> >>
> >> I guess I understand a bit. I was confused by your use of "upstream".
> >> It seems you use it the wrong way, so for you "upstream" is what the
> >> MIPS enterprise world wants/needs, while "downstream" is what the
> >> open-source community wants/needs.
> >>
> >> If MIPS enterprise doesn't want a Malta machine model with 3GB of RAM,
> >> they can disable it in their downstream.
> >> If it helps the upstream community, the model is wrong anyway by using
> >> 2GB. It would be disastrous for all user to restrict the malta machine
> >> to 1GB upstream.
> >>
> >
> > No, when I said "upstream" I meant what "upstream" always meant - our
> > central QEMU repository.
> >
> > There is no different treatment of proposals whatever or whoever is
> > the origin of the proposal. The proposals are judged only on their
> > technical merits.
> >
> > It is very difficult to cooperate with you if you constantly put in my
> > mouth what I would never say, like you did more than once in this
> > thread.
>
> That would help if you answer all questions (so I don't have to guess)
> and explain why you decide to say "no", so I don't have to ask you
> for details.
>
> So I don't understand why you treat "upstream" as only owned by MIPS
> enterprise. Aurelien put me here to represent the hobbyist users.
> You can not simply say "no", we have to discuss and get a consensus
> for the best of all the community, not only your company/employer.
> This is not always easy, but this is open source, you have to work
> in the open with other contributors, and can not only dictate.
>

I explained to you clearly the purely technical reasons why your
proposal is not good, and the reasons have nothing to do with
enterprize or hobist terms (this is the third time, the third strike,
in this single thread, you claim I said that I did not) and have
nothing to add.

Regards,
Aleksandar

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

[Thomas Huth]

On 30/06/2020 13.17, Aleksandar Markovic wrote:
> 
> 
> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org 
> <mailto:f4bug@amsat.org>> је написао/ла:
> 
>     On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
>      >
>      >
>      > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
>     <mailto:f4bug@amsat.org>
>      > <mailto: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>
>     <mailto: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>>
>      >     > > <mailto: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/>>
>      >     > >     <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?
> 
> 
> 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 the following patch in your 
next mips pull request to avoid that mips users spoil their machines 
with virtual-only features:

diff a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -6,10 +6,10 @@ CONFIG_SEMIHOSTING=y
  CONFIG_ISA_BUS=y
  CONFIG_PCI=y
  CONFIG_PCI_DEVICES=y
+CONFIG_VIRTIO_PCI=n
  CONFIG_VGA_ISA=y
  CONFIG_VGA_ISA_MM=y
  CONFIG_VGA_CIRRUS=y
-CONFIG_VMWARE_VGA=y
  CONFIG_SERIAL=y
  CONFIG_SERIAL_ISA=y
  CONFIG_PARALLEL=y

;-)

No, seriously, as far as I can tell, QEMU was never in that "we strictly 
only emulate real hardware" camp, even the homepage talks about 
"virtualizer".

But introducing a separate machine for this feature sounds a little bit 
excessive for me, too. What about introducing a machine property for the 
max-ram-size? With the default value, the machine could restrict the ram 
sizes to the values that are possible with the real hardware, and only 
if the (advanced) user tweaks the property, it would be possible to set 
bigger values. Just my 0.02 €.

  Thomas


PS: Why does mips use CONFIG_VMWARE_VGA=y at all? Is VMWARE also 
available for mips?

PPS: Why is mips still not using proper Kconfig settings yet?

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 3:36 PM, Thomas Huth wrote:
> On 30/06/2020 13.17, Aleksandar Markovic wrote:
>>
>>
>> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
>> <mailto:f4bug@amsat.org>> је написао/ла:
>>
>>     On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
>>      >
>>      >
>>      > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
>>     <mailto:f4bug@amsat.org>
>>      > <mailto: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>
>>     <mailto: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>>
>>      >     > > <mailto: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/>>
>>      >     > >     <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?
>>
>>
>> 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 the following patch in your
> next mips pull request to avoid that mips users spoil their machines
> with virtual-only features:
> 
> diff a/default-configs/mips-softmmu-common.mak
> b/default-configs/mips-softmmu-common.mak
> --- a/default-configs/mips-softmmu-common.mak
> +++ b/default-configs/mips-softmmu-common.mak
> @@ -6,10 +6,10 @@ CONFIG_SEMIHOSTING=y
>  CONFIG_ISA_BUS=y
>  CONFIG_PCI=y
>  CONFIG_PCI_DEVICES=y
> +CONFIG_VIRTIO_PCI=n
>  CONFIG_VGA_ISA=y
>  CONFIG_VGA_ISA_MM=y
>  CONFIG_VGA_CIRRUS=y
> -CONFIG_VMWARE_VGA=y
>  CONFIG_SERIAL=y
>  CONFIG_SERIAL_ISA=y
>  CONFIG_PARALLEL=y
> 
> ;-)
> 
> No, seriously, as far as I can tell, QEMU was never in that "we strictly
> only emulate real hardware" camp, even the homepage talks about
> "virtualizer".
> 
> But introducing a separate machine for this feature sounds a little bit
> excessive for me, too. What about introducing a machine property for the
> max-ram-size? With the default value, the machine could restrict the ram
> sizes to the values that are possible with the real hardware, and only
> if the (advanced) user tweaks the property, it would be possible to set
> bigger values. Just my 0.02 €.
> 
>  Thomas
> 
> 
> PS: Why does mips use CONFIG_VMWARE_VGA=y at all? Is VMWARE also
> available for mips?
> 
> PPS: Why is mips still not using proper Kconfig settings yet?

Related to "ACPI + ICH9 + PIIX4" interdependence with X86. Fixing MIPS
would break X86. We can not break X86 (and there is little interest from
enterprise X86 on solving MIPS emulation problems).

Then I consumed all the time my manager granted me to work on it, so
it is very low in my list. If someone else want to do it, help welcomed.

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

[Aleksandar Markovic]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

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

> On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé <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/>
> >
> >     - 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
> >
>

[-- Attachment #2: Type: text/html, Size: 3433 bytes --]

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 12:54 PM, Aleksandar Markovic wrote:
> 
> 
> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> <mailto:f4bug@amsat.org>> је написао/ла:
> 
>     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).
> 
> 
> 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

[Aleksandar Markovic]

[-- Attachment #1: Type: text/plain, Size: 3702 bytes --]

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

> On 6/30/20 12:54 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> > <mailto:f4bug@amsat.org>> је написао/ла:
> >
> >     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).
> >
> >
> > 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
> >     >
> >
>

[-- Attachment #2: Type: text/html, Size: 5587 bytes --]