[PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Philippe Mathieu-Daudé]

Hi,

This series add a new 'malta-strict' machine, that aims to properly
model the real hardware (which is not what the current 'malta'
machine models).

As a bonus for Debian builders, a 'malta-unleashed' machine RFC
patch is included. This might start another endless discussion
upstream, but this is not the point of, so I still include it
for people to test. The rest of the series is candidate for merging
in mainstream QEMU.

Philippe Mathieu-Daudé (6):
  hw/mips/malta: Trivial code movement
  hw/mips/malta: Register the machine as a TypeInfo
  hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
  hw/mips/malta: Introduce the 'malta-strict' machine
  hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
  hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine

 hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 111 insertions(+), 14 deletions(-)

-- 
2.21.3

[PATCH v2 1/6] 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 v2 2/6] 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 | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 5b371c1e34..2c363fe099 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-base")
+
 typedef struct {
     MemoryRegion iomem;
     MemoryRegion iomem_lo; /* 0 - 0x900 */
@@ -1433,10 +1435,19 @@ 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_common_class_init(ObjectClass *oc, void *data)
 {
-    mc->desc = "MIPS Malta Core LV";
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->init = mips_malta_init;
+    mc->default_ram_id = "mips_malta.ram";
+}
+
+static void malta_machine_default_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    mc->desc = "MIPS Malta Core LV";
     mc->block_default_type = IF_IDE;
     mc->max_cpus = 16;
     mc->is_default = true;
@@ -1445,7 +1456,20 @@ static void mips_malta_machine_init(MachineClass *mc)
 #else
     mc->default_cpu_type = MIPS_CPU_TYPE_NAME("24Kf");
 #endif
-    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,
+        .class_init    = malta_machine_default_class_init,
+    },
+    {
+        .name          = TYPE_MALTA_MACHINE,
+        .parent        = TYPE_MACHINE,
+        .class_init    = malta_machine_common_class_init,
+        .abstract      = true,
+    }
+};
+
+DEFINE_TYPES(malta_machine_types)
-- 
2.21.3

[PATCH v2 3/6] 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 | 30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 2c363fe099..17a1c0d1c4 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-base")
+#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_common_class_init(ObjectClass *oc, void *data)
 static void malta_machine_default_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
+    MaltaMachineClass *mmc = MALTA_MACHINE_CLASS(oc);
 
     mc->desc = "MIPS Malta Core LV";
     mc->block_default_type = IF_IDE;
@@ -1456,6 +1475,7 @@ static void malta_machine_default_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[] = {
-- 
2.21.3

Re: [PATCH v2 3/6] hw/mips/malta: Introduce MaltaMachineClass::max_ramsize

[Philippe Mathieu-Daudé]

On 6/30/20 4:52 PM, Philippe Mathieu-Daudé wrote:
> 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 | 30 +++++++++++++++++++++++++-----
>  1 file changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/mips/malta.c b/hw/mips/malta.c
> index 2c363fe099..17a1c0d1c4 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-base")
> +#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_common_class_init(ObjectClass *oc, void *data)
>  static void malta_machine_default_class_init(ObjectClass *oc, void *data)
>  {
>      MachineClass *mc = MACHINE_CLASS(oc);
> +    MaltaMachineClass *mmc = MALTA_MACHINE_CLASS(oc);
>  
>      mc->desc = "MIPS Malta Core LV";
>      mc->block_default_type = IF_IDE;
> @@ -1456,6 +1475,7 @@ static void malta_machine_default_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[] = {
> 

Missing:

-- >8 --
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1541,6 +1541,7 @@ static const TypeInfo malta_machine_types[] = {
         .name          = TYPE_MALTA_MACHINE,
         .parent        = TYPE_MACHINE,
         .class_init    = malta_machine_common_class_init,
+        .class_size    = sizeof(MaltaMachineClass),
         .abstract      = true,
     }
 };
---

[PATCH v2 4/6] hw/mips/malta: Introduce the 'malta-strict' machine

[Philippe Mathieu-Daudé]

Introduce the 'malta-strict' machine, aiming to have the same
limitations as real hardware.

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 datasheet 'MIPS Document Number: MD00051 Revision 01.07'.

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

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 17a1c0d1c4..209237d066 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1478,12 +1478,34 @@ static void malta_machine_default_class_init(ObjectClass *oc, void *data)
     mmc->max_ramsize = 2 * GiB;
 }
 
+static void malta_machine_strict_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"),
         .parent        = TYPE_MALTA_MACHINE,
         .class_init    = malta_machine_default_class_init,
     },
+    {
+        .name          = MACHINE_TYPE_NAME("malta-strict"),
+        .parent        = TYPE_MALTA_MACHINE,
+        .class_init    = malta_machine_strict_class_init,
+    },
     {
         .name          = TYPE_MALTA_MACHINE,
         .parent        = TYPE_MACHINE,
-- 
2.21.3

[PATCH v2 5/6] hw/mips/malta: Verify malta-strict 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 209237d066..63c1d5ea5f 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-base")
 #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
@@ -1493,6 +1502,7 @@ static void malta_machine_strict_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 v2 6/6] hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine

[Philippe Mathieu-Daudé]

Introduce the 'malta-unleashed' machine. This machine does not
model any existing hardware (as the default 'malta' neither model
a real hardware). The purpose of this machine is to allow user
of the current 'malta' machine to use more RAM, as it has been
reported to be useful for build farms.

References:
- https://www.mail-archive.com/debian-mips@lists.debian.org/msg10912.html
- https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004844.html
- https://www.mail-archive.com/qemu-devel@nongnu.org/msg691406.html

Cc: debian-mips@lists.debian.org
Cc: Ximin Luo <infinity0@debian.org>
Cc: Martin Quinson <mquinson@debian.org>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Jonathan Jackson <jnthjackson@gmail.com>
Suggested-by: Yunqiang Su <ysu@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
This patch is RFC because an upstream QEMU maintainer disagree
with this approach, but I'm sending it so interested folks in
the community (Debian or other) can test it.

Previous discussion on Jiaxun Yang's patch:
https://patchwork.kernel.org/patch/11416915/
---
 hw/mips/malta.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 63c1d5ea5f..1695994493 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1505,6 +1505,20 @@ static void malta_machine_strict_class_init(ObjectClass *oc, void *data)
     mmc->verify_dimm_sizes = true;
 };
 
+#ifdef TARGET_MIPS64
+static void malta_machine_unleashed_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+    MaltaMachineClass *mmc = MALTA_MACHINE_CLASS(oc);
+
+    mc->desc = "MIPS Malta Core LV (physically unlimited)";
+    mc->block_default_type = IF_IDE;
+    mc->max_cpus = 16;
+    mc->default_cpu_type = MIPS_CPU_TYPE_NAME("20Kc");
+    mmc->max_ramsize = 3 * GiB;
+}
+#endif /* TARGET_MIPS64 */
+
 static const TypeInfo malta_machine_types[] = {
     {
         .name          = MACHINE_TYPE_NAME("malta"),
@@ -1516,6 +1530,13 @@ static const TypeInfo malta_machine_types[] = {
         .parent        = TYPE_MALTA_MACHINE,
         .class_init    = malta_machine_strict_class_init,
     },
+#ifdef TARGET_MIPS64
+    {
+        .name          = MACHINE_TYPE_NAME("malta-unleashed"),
+        .parent        = TYPE_MALTA_MACHINE,
+        .class_init    = malta_machine_unleashed_class_init,
+    },
+#endif /* TARGET_MIPS64 */
     {
         .name          = TYPE_MALTA_MACHINE,
         .parent        = TYPE_MACHINE,
-- 
2.21.3

Re: [PATCH v2 6/6] hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine

[Daniel P. Berrangé]

On Tue, Jun 30, 2020 at 04:52:36PM +0200, Philippe Mathieu-Daudé wrote:
> Introduce the 'malta-unleashed' machine. This machine does not
> model any existing hardware (as the default 'malta' neither model
> a real hardware). The purpose of this machine is to allow user
> of the current 'malta' machine to use more RAM, as it has been
> reported to be useful for build farms.
> 
> References:
> - https://www.mail-archive.com/debian-mips@lists.debian.org/msg10912.html
> - https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004844.html
> - https://www.mail-archive.com/qemu-devel@nongnu.org/msg691406.html

I'm not convinced that there's any real value in adding the malta-strict
and malta-unleashed machine types.

If you want to closely model a real physical machine it doesn't matter
what the "max ram" setting says - you can just choose a "-m MB" value
to match the physical machine you want to model.

Similarly if users want to exceed what the physical machine would do
there's no compelling reason for QEMU to artificially prevent that
or force use of a different machine.  Neither i440fx or q35 force
users to the max RAM limit of the physical machine they were originally
designed from. We have frequently just bumped the max limits in QEMU
for i440fx/q35 as we had users who requested a higher level.

IIUC, The current 2 GB limit is just a historical artifact from the
limited address space in 32-bit, which we don't have to be bound by
for 64-bit. 

IOW, instead of adding new machine types I would think we can just
modify the existing limit for TARGET_MIPS64, by doing something akin
to:


diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index d95926a89c..48e34da39c 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1247,9 +1247,14 @@ void mips_malta_init(MachineState *machine)
     mips_create_cpu(machine, s, &cbus_irq, &i8259_irq);
 
     /* allocate RAM */
-    if (ram_size > 2 * GiB) {
+#ifdef TARGET_MIPS64
+#define MAX_RAM_MB 3056
+#else
+#define MAX_RAM_MB 2048
+#endif
+    if (ram_size > MAX_RAM_MB * MiB) {
         error_report("Too much memory for this machine: %" PRId64 "MB,"
-                     " maximum 2048MB", ram_size / MiB);
+                     " maximum " MAX_RAM_MB "MB", ram_size / MiB);
         exit(1);
     }
 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
написао/ла:
>
> Hi,
>
> This series add a new 'malta-strict' machine, that aims to properly
> model the real hardware (which is not what the current 'malta'
> machine models).
>
> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
> patch is included. This might start another endless discussion
> upstream, but this is not the point of, so I still include it
> for people to test. The rest of the series is candidate for merging
> in mainstream QEMU.
>
> Philippe Mathieu-Daudé (6):
>   hw/mips/malta: Trivial code movement
>   hw/mips/malta: Register the machine as a TypeInfo
>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>   hw/mips/malta: Introduce the 'malta-strict' machine
>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
>
>  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
>  1 file changed, 111 insertions(+), 14 deletions(-)
>
> --

This whole series is based on idea of emulating physically
non-existing feature, and as such violates the fundamental principles
of QEMU.

As such, not acceptable for upstreaming.

I don't see the point of sending again the same series, in just
cosmetically different form, if it was said to you that the concept is
wrong.

Regards,
Aleksandar


> 2.21.3
>

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Philippe Mathieu-Daudé]

On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> написао/ла:
>>
>> Hi,
>>
>> This series add a new 'malta-strict' machine, that aims to properly
>> model the real hardware (which is not what the current 'malta'
>> machine models).
>>
>> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
>> patch is included. This might start another endless discussion
>> upstream, but this is not the point of, so I still include it
>> for people to test. The rest of the series is candidate for merging
>> in mainstream QEMU.
>>
>> Philippe Mathieu-Daudé (6):
>>   hw/mips/malta: Trivial code movement
>>   hw/mips/malta: Register the machine as a TypeInfo
>>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>>   hw/mips/malta: Introduce the 'malta-strict' machine
>>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
>>
>>  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
>>  1 file changed, 111 insertions(+), 14 deletions(-)
>>
>> --
> 
> This whole series is based on idea of emulating physically
> non-existing feature, and as such violates the fundamental principles
> of QEMU.
> 
> As such, not acceptable for upstreaming.
> 
> I don't see the point of sending again the same series, in just
> cosmetically different form, if it was said to you that the concept is
> wrong.

Have you looked at the patches? What "violates the fundamental
principles of QEMU" is the code currently in mainstream. Should
we remove it? I can send a patch for it if it pleases you, but
you will make QEMU unuseful for many distribution users.

What this series does is emulate the physically existing feature
that are not yet emulated in QEMU.

Please refer to the datasheet 'MIPS Document Number: MD00051
Revision 01.07' before rejecting this series, and find the
correct arguments.

Thanks.

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

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

уто, 30. јун 2020. у 18:46 Philippe Mathieu-Daudé <f4bug@amsat.org> је
написао/ла:
>
> On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
> > уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> > написао/ла:
> >>
> >> Hi,
> >>
> >> This series add a new 'malta-strict' machine, that aims to properly
> >> model the real hardware (which is not what the current 'malta'
> >> machine models).
> >>
> >> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
> >> patch is included. This might start another endless discussion
> >> upstream, but this is not the point of, so I still include it
> >> for people to test. The rest of the series is candidate for merging
> >> in mainstream QEMU.
> >>
> >> Philippe Mathieu-Daudé (6):
> >>   hw/mips/malta: Trivial code movement
> >>   hw/mips/malta: Register the machine as a TypeInfo
> >>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> >>   hw/mips/malta: Introduce the 'malta-strict' machine
> >>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
> >>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
> >>
> >>  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
> >>  1 file changed, 111 insertions(+), 14 deletions(-)
> >>
> >> --
> >
> > This whole series is based on idea of emulating physically
> > non-existing feature, and as such violates the fundamental principles
> > of QEMU.
> >
> > As such, not acceptable for upstreaming.
> >
> > I don't see the point of sending again the same series, in just
> > cosmetically different form, if it was said to you that the concept is
> > wrong.
>
> Have you looked at the patches? What "violates the fundamental
> principles of QEMU" is the code currently in mainstream. Should
> we remove it? I can send a patch for it if it pleases you, but
> you will make QEMU unuseful for many distribution users.
>

Past mistakes are past mistakes. We have to live with them. And not
make them in the future.

I see the whole series as a precursor for your change that repeats
past mistakes, a "wolf in sheep clothing".

That's why I reject the series as a whole.

Yours,
Aleksandar

> What this series does is emulate the physically existing feature
> that are not yet emulated in QEMU.
>
> Please refer to the datasheet 'MIPS Document Number: MD00051
> Revision 01.07' before rejecting this series, and find the
> correct arguments.
>
> Thanks.
>
> >
> > Regards,
> > Aleksandar
> >
> >
> >> 2.21.3
> >>
> >

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Philippe Mathieu-Daudé]

On 6/30/20 6:55 PM, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 18:46 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> написао/ла:
>>
>> On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
>>> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
>>> написао/ла:
>>>>
>>>> Hi,
>>>>
>>>> This series add a new 'malta-strict' machine, that aims to properly
>>>> model the real hardware (which is not what the current 'malta'
>>>> machine models).
>>>>
>>>> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
>>>> patch is included. This might start another endless discussion
>>>> upstream, but this is not the point of, so I still include it
>>>> for people to test. The rest of the series is candidate for merging
>>>> in mainstream QEMU.
>>>>
>>>> Philippe Mathieu-Daudé (6):
>>>>   hw/mips/malta: Trivial code movement
>>>>   hw/mips/malta: Register the machine as a TypeInfo
>>>>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>>>>   hw/mips/malta: Introduce the 'malta-strict' machine
>>>>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>>>>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
>>>>
>>>>  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
>>>>  1 file changed, 111 insertions(+), 14 deletions(-)
>>>>
>>>> --
>>>
>>> This whole series is based on idea of emulating physically
>>> non-existing feature, and as such violates the fundamental principles
>>> of QEMU.
>>>
>>> As such, not acceptable for upstreaming.
>>>
>>> I don't see the point of sending again the same series, in just
>>> cosmetically different form, if it was said to you that the concept is
>>> wrong.
>>
>> Have you looked at the patches? What "violates the fundamental
>> principles of QEMU" is the code currently in mainstream. Should
>> we remove it? I can send a patch for it if it pleases you, but
>> you will make QEMU unuseful for many distribution users.
>>
> 
> Past mistakes are past mistakes. We have to live with them. And not
> make them in the future.
> 
> I see the whole series as a precursor for your change that repeats
> past mistakes, a "wolf in sheep clothing".
> 
> That's why I reject the series as a whole.

As a co-maintainer I don't accept that.

The 'malta' machine is not changed, the series adds the 'malta-strict'
machine which check the RAM restriction:

$ qemu-system-mips -M malta-strict -bios /dev/null -m 512
qemu-system-mips: Too much memory for this machine: 512 MiB, maximum 256 MiB

$ qemu-system-mips -M malta-strict -bios /dev/null -m 252
qemu-system-mips: RAM size must be the combination of 4 powers of 2

$ qemu-system-mips -M malta-strict -monitor stdio -S -bios /dev/null -m 100
QEMU 5.0.50 monitor - type 'help' for more information
(qemu) info mtree
address-space: memory
  0000000000000000-ffffffffffffffff (prio 0, i/o): system
    0000000000000000-00000000063fffff (prio 0, ram): alias
mips_malta_low_preio.ram @mips_malta.ram 0000000000000000-00000000063fffff

100 = 64 + 32 + 2 + 2

> 
> Yours,
> Aleksandar
> 
>> What this series does is emulate the physically existing feature
>> that are not yet emulated in QEMU.
>>
>> Please refer to the datasheet 'MIPS Document Number: MD00051
>> Revision 01.07' before rejecting this series, and find the
>> correct arguments.
>>
>> Thanks.
>>
>>>
>>> Regards,
>>> Aleksandar
>>>
>>>
>>>> 2.21.3
>>>>
>>>
> 

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

уто, 30. јун 2020. у 19:16 Philippe Mathieu-Daudé <f4bug@amsat.org> је
написао/ла:
>
> On 6/30/20 6:55 PM, Aleksandar Markovic wrote:
> > уто, 30. јун 2020. у 18:46 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> > написао/ла:
> >>
> >> On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
> >>> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> >>> написао/ла:
> >>>>
> >>>> Hi,
> >>>>
> >>>> This series add a new 'malta-strict' machine, that aims to properly
> >>>> model the real hardware (which is not what the current 'malta'
> >>>> machine models).
> >>>>
> >>>> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
> >>>> patch is included. This might start another endless discussion
> >>>> upstream, but this is not the point of, so I still include it
> >>>> for people to test. The rest of the series is candidate for merging
> >>>> in mainstream QEMU.
> >>>>
> >>>> Philippe Mathieu-Daudé (6):
> >>>>   hw/mips/malta: Trivial code movement
> >>>>   hw/mips/malta: Register the machine as a TypeInfo
> >>>>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> >>>>   hw/mips/malta: Introduce the 'malta-strict' machine
> >>>>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
> >>>>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
> >>>>
> >>>>  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
> >>>>  1 file changed, 111 insertions(+), 14 deletions(-)
> >>>>
> >>>> --
> >>>
> >>> This whole series is based on idea of emulating physically
> >>> non-existing feature, and as such violates the fundamental principles
> >>> of QEMU.
> >>>
> >>> As such, not acceptable for upstreaming.
> >>>
> >>> I don't see the point of sending again the same series, in just
> >>> cosmetically different form, if it was said to you that the concept is
> >>> wrong.
> >>
> >> Have you looked at the patches? What "violates the fundamental
> >> principles of QEMU" is the code currently in mainstream. Should
> >> we remove it? I can send a patch for it if it pleases you, but
> >> you will make QEMU unuseful for many distribution users.
> >>
> >
> > Past mistakes are past mistakes. We have to live with them. And not
> > make them in the future.
> >
> > I see the whole series as a precursor for your change that repeats
> > past mistakes, a "wolf in sheep clothing".
> >
> > That's why I reject the series as a whole.
>
> As a co-maintainer I don't accept that.
>

I offered you the full maintainership for Malta.

You said you can proveide only "Odd fiexes".

I had to jump in to provide "Maintained" status.

Therefore, I provide the higher level of maintainership, and you have
to respect that. But you don't.

Regards,
Aleksandar

> The 'malta' machine is not changed, the series adds the 'malta-strict'
> machine which check the RAM restriction:
>
> $ qemu-system-mips -M malta-strict -bios /dev/null -m 512
> qemu-system-mips: Too much memory for this machine: 512 MiB, maximum 256 MiB
>
> $ qemu-system-mips -M malta-strict -bios /dev/null -m 252
> qemu-system-mips: RAM size must be the combination of 4 powers of 2
>
> $ qemu-system-mips -M malta-strict -monitor stdio -S -bios /dev/null -m 100
> QEMU 5.0.50 monitor - type 'help' for more information
> (qemu) info mtree
> address-space: memory
>   0000000000000000-ffffffffffffffff (prio 0, i/o): system
>     0000000000000000-00000000063fffff (prio 0, ram): alias
> mips_malta_low_preio.ram @mips_malta.ram 0000000000000000-00000000063fffff
>
> 100 = 64 + 32 + 2 + 2
>
> >
> > Yours,
> > Aleksandar
> >
> >> What this series does is emulate the physically existing feature
> >> that are not yet emulated in QEMU.
> >>
> >> Please refer to the datasheet 'MIPS Document Number: MD00051
> >> Revision 01.07' before rejecting this series, and find the
> >> correct arguments.
> >>
> >> Thanks.
> >>
> >>>
> >>> Regards,
> >>> Aleksandar
> >>>
> >>>
> >>>> 2.21.3
> >>>>
> >>>
> >

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Philippe Mathieu-Daudé]

On 6/30/20 7:28 PM, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 19:16 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> написао/ла:
>>
>> On 6/30/20 6:55 PM, Aleksandar Markovic wrote:
>>> уто, 30. јун 2020. у 18:46 Philippe Mathieu-Daudé <f4bug@amsat.org> је
>>> написао/ла:
>>>>
>>>> On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
>>>>> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
>>>>> написао/ла:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This series add a new 'malta-strict' machine, that aims to properly
>>>>>> model the real hardware (which is not what the current 'malta'
>>>>>> machine models).
>>>>>>
>>>>>> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
>>>>>> patch is included. This might start another endless discussion
>>>>>> upstream, but this is not the point of, so I still include it
>>>>>> for people to test. The rest of the series is candidate for merging
>>>>>> in mainstream QEMU.
>>>>>>
>>>>>> Philippe Mathieu-Daudé (6):
>>>>>>   hw/mips/malta: Trivial code movement
>>>>>>   hw/mips/malta: Register the machine as a TypeInfo
>>>>>>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>>>>>>   hw/mips/malta: Introduce the 'malta-strict' machine
>>>>>>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>>>>>>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
>>>>>>
>>>>>>  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
>>>>>>  1 file changed, 111 insertions(+), 14 deletions(-)
>>>>>>
>>>>>> --
>>>>>
>>>>> This whole series is based on idea of emulating physically
>>>>> non-existing feature, and as such violates the fundamental principles
>>>>> of QEMU.
>>>>>
>>>>> As such, not acceptable for upstreaming.
>>>>>
>>>>> I don't see the point of sending again the same series, in just
>>>>> cosmetically different form, if it was said to you that the concept is
>>>>> wrong.
>>>>
>>>> Have you looked at the patches? What "violates the fundamental
>>>> principles of QEMU" is the code currently in mainstream. Should
>>>> we remove it? I can send a patch for it if it pleases you, but
>>>> you will make QEMU unuseful for many distribution users.
>>>>
>>>
>>> Past mistakes are past mistakes. We have to live with them. And not
>>> make them in the future.
>>>
>>> I see the whole series as a precursor for your change that repeats
>>> past mistakes, a "wolf in sheep clothing".
>>>
>>> That's why I reject the series as a whole.
>>
>> As a co-maintainer I don't accept that.
>>
> 
> I offered you the full maintainership for Malta.
> 
> You said you can proveide only "Odd fiexes".
> 
> I had to jump in to provide "Maintained" status.
> 
> Therefore, I provide the higher level of maintainership, and you have
> to respect that. But you don't.

FYI we are listed as co-maintainer:

Malta
M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
M: Philippe Mathieu-Daudé <f4bug@amsat.org>
R: Aurelien Jarno <aurelien@aurel32.net>
S: Maintained

There is no difference of level. If you don't want my help and plan
to destroy the hobbyist MIPS aspect of QEMU please kick me out, as
I don't want to be responsible for dictating in an open source project.

You can also relinquish your responsibility in Malta and focus on what
is important for your company.

> 
> Regards,
> Aleksandar
> 
>> The 'malta' machine is not changed, the series adds the 'malta-strict'
>> machine which check the RAM restriction:
>>
>> $ qemu-system-mips -M malta-strict -bios /dev/null -m 512
>> qemu-system-mips: Too much memory for this machine: 512 MiB, maximum 256 MiB
>>
>> $ qemu-system-mips -M malta-strict -bios /dev/null -m 252
>> qemu-system-mips: RAM size must be the combination of 4 powers of 2
>>
>> $ qemu-system-mips -M malta-strict -monitor stdio -S -bios /dev/null -m 100
>> QEMU 5.0.50 monitor - type 'help' for more information
>> (qemu) info mtree
>> address-space: memory
>>   0000000000000000-ffffffffffffffff (prio 0, i/o): system
>>     0000000000000000-00000000063fffff (prio 0, ram): alias
>> mips_malta_low_preio.ram @mips_malta.ram 0000000000000000-00000000063fffff
>>
>> 100 = 64 + 32 + 2 + 2
>>
>>>
>>> Yours,
>>> Aleksandar
>>>
>>>> What this series does is emulate the physically existing feature
>>>> that are not yet emulated in QEMU.
>>>>
>>>> Please refer to the datasheet 'MIPS Document Number: MD00051
>>>> Revision 01.07' before rejecting this series, and find the
>>>> correct arguments.
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>> Regards,
>>>>> Aleksandar
>>>>>
>>>>>
>>>>>> 2.21.3
>>>>>>
>>>>>
>>>
> 

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Richard Henderson]

On 6/30/20 10:28 AM, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 19:16 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> написао/ла:
>>
>> On 6/30/20 6:55 PM, Aleksandar Markovic wrote:
>>> уто, 30. јун 2020. у 18:46 Philippe Mathieu-Daudé <f4bug@amsat.org> је
>>> написао/ла:
>>>>
>>>> On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
>>>>> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
>>>>> написао/ла:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This series add a new 'malta-strict' machine, that aims to properly
>>>>>> model the real hardware (which is not what the current 'malta'
>>>>>> machine models).
>>>>>>
>>>>>> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
>>>>>> patch is included. This might start another endless discussion
>>>>>> upstream, but this is not the point of, so I still include it
>>>>>> for people to test. The rest of the series is candidate for merging
>>>>>> in mainstream QEMU.
>>>>>>
>>>>>> Philippe Mathieu-Daudé (6):
>>>>>>   hw/mips/malta: Trivial code movement
>>>>>>   hw/mips/malta: Register the machine as a TypeInfo
>>>>>>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>>>>>>   hw/mips/malta: Introduce the 'malta-strict' machine
>>>>>>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>>>>>>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
>>>>>>
>>>>>>  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
>>>>>>  1 file changed, 111 insertions(+), 14 deletions(-)
>>>>>>
>>>>>> --
>>>>>
>>>>> This whole series is based on idea of emulating physically
>>>>> non-existing feature, and as such violates the fundamental principles
>>>>> of QEMU.
>>>>>
>>>>> As such, not acceptable for upstreaming.
>>>>>
>>>>> I don't see the point of sending again the same series, in just
>>>>> cosmetically different form, if it was said to you that the concept is
>>>>> wrong.
>>>>
>>>> Have you looked at the patches? What "violates the fundamental
>>>> principles of QEMU" is the code currently in mainstream. Should
>>>> we remove it? I can send a patch for it if it pleases you, but
>>>> you will make QEMU unuseful for many distribution users.
>>>>
>>>
>>> Past mistakes are past mistakes. We have to live with them. And not
>>> make them in the future.
>>>
>>> I see the whole series as a precursor for your change that repeats
>>> past mistakes, a "wolf in sheep clothing".
>>>
>>> That's why I reject the series as a whole.
>>
>> As a co-maintainer I don't accept that.
>>
> 
> I offered you the full maintainership for Malta.
> 
> You said you can proveide only "Odd fiexes".
> 
> I had to jump in to provide "Maintained" status.
> 
> Therefore, I provide the higher level of maintainership, and you have
> to respect that. But you don't.

You need to cool your jets here, Aleksandar.

You do not have some mythical "higher level" of maintainership.  Nor, as far as
I can tell, are you actually doing anything with Malta whereas Philippe is.


r~

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Thomas Huth]

On 30/06/2020 17.38, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> написао/ла:
>>
>> Hi,
>>
>> This series add a new 'malta-strict' machine, that aims to properly
>> model the real hardware (which is not what the current 'malta'
>> machine models).
>>
>> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
>> patch is included. This might start another endless discussion
>> upstream, but this is not the point of, so I still include it
>> for people to test. The rest of the series is candidate for merging
>> in mainstream QEMU.
>>
>> Philippe Mathieu-Daudé (6):
>>    hw/mips/malta: Trivial code movement
>>    hw/mips/malta: Register the machine as a TypeInfo
>>    hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>>    hw/mips/malta: Introduce the 'malta-strict' machine
>>    hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>>    hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
>>
>>   hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
>>   1 file changed, 111 insertions(+), 14 deletions(-)
>>
>> --
> 
> This whole series is based on idea of emulating physically
> non-existing feature, and as such violates the fundamental principles
> of QEMU.
> 
> As such, not acceptable for upstreaming.

  Hi Aleksandar,

could you please point me to the spot where we declare this "fundamental 
principle" of QEMU? Sorry, but I must have missed this piece of 
information so far. And could you please enlighten me what we should do 
now with virtio, since most of these devices also are physically 
non-existent?

  Thanks,
   Thomas

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Daniel P. Berrangé]

On Tue, Jun 30, 2020 at 05:38:25PM +0200, Aleksandar Markovic wrote:
> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé <f4bug@amsat.org> је
> написао/ла:
> >
> > Hi,
> >
> > This series add a new 'malta-strict' machine, that aims to properly
> > model the real hardware (which is not what the current 'malta'
> > machine models).
> >
> > As a bonus for Debian builders, a 'malta-unleashed' machine RFC
> > patch is included. This might start another endless discussion
> > upstream, but this is not the point of, so I still include it
> > for people to test. The rest of the series is candidate for merging
> > in mainstream QEMU.
> >
> > Philippe Mathieu-Daudé (6):
> >   hw/mips/malta: Trivial code movement
> >   hw/mips/malta: Register the machine as a TypeInfo
> >   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> >   hw/mips/malta: Introduce the 'malta-strict' machine
> >   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
> >   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
> >
> >  hw/mips/malta.c | 125 ++++++++++++++++++++++++++++++++++++++++++------
> >  1 file changed, 111 insertions(+), 14 deletions(-)
> >
> > --
> 
> This whole series is based on idea of emulating physically
> non-existing feature, and as such violates the fundamental principles
> of QEMU.

On x86 we model a i440fx from 1995. Max RAM in 1995 was on the order
of 10's of MB, but we run it with *multi-TB* of RAM in QEMU. There's
examples of this all over QEMU.

> As such, not acceptable for upstreaming.

I think this is quite unreasonable, especially considering this series is
addressing a real world problem that users of QEMU malta are facing with
insufficient RAM. QEMU exists to help users get their work done

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|