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

[PATCH v3 0/5] 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).

Since v2:
- Initialize missing malta_machine_types::class_size
- Remove RFC patch that confuses Aleksandar
- Added examples of 'malta-strict' use

$ git backport-diff -u v2
Key:
[----] : patches are identical
[####] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/5:[----] [--] 'hw/mips/malta: Trivial code movement'
002/5:[----] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
004/5:[----] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
005/5:[----] [--] 'hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes'

Philippe Mathieu-Daudé (5):
  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.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 91 insertions(+), 14 deletions(-)

-- 
2.21.3

[PATCH v3 1/5] 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 v3 2/5] 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 v3 3/5] 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 2c363fe099..fd4964e8b0 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[] = {
@@ -1468,6 +1488,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,
     }
 };
-- 
2.21.3

[PATCH v3 4/5] 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'.

Example when asking a too big amount of memory:

  $ 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

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 fd4964e8b0..ac4a618751 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 v3 5/5] 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.

Example when asking a combination not power of 2:

  $ 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

Working example (as 100 = 64 + 32 + 2 + 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

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 ac4a618751..17f5833a94 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

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

[Aleksandar Markovic]

As, in a very clear way, evidenced from the previous versions of this
series, this series real goal was not not to create some new
"malta-strict" machine, but to prepare path to creation of some
imagined "malta-unleashed" machine which will, to the contrary of
proclaimed goal, create a machine that could never exist in reality.
That is why I can't accept this series.

Regards,
Aleksandar


уто, 30. јун 2020. у 21:58 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).
>
> Since v2:
> - Initialize missing malta_machine_types::class_size
> - Remove RFC patch that confuses Aleksandar
> - Added examples of 'malta-strict' use
>
> $ git backport-diff -u v2
> Key:
> [----] : patches are identical
> [####] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
>
> 001/5:[----] [--] 'hw/mips/malta: Trivial code movement'
> 002/5:[----] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
> 003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
> 004/5:[----] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
> 005/5:[----] [--] 'hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes'
>
> Philippe Mathieu-Daudé (5):
>   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.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 91 insertions(+), 14 deletions(-)
>
> --
> 2.21.3
>
>

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

[BALATON Zoltan]

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

On Tue, 30 Jun 2020, Aleksandar Markovic wrote:
> As, in a very clear way, evidenced from the previous versions of this
> series, this series real goal was not not to create some new
> "malta-strict" machine, but to prepare path to creation of some
> imagined "malta-unleashed" machine which will, to the contrary of
> proclaimed goal, create a machine that could never exist in reality.
> That is why I can't accept this series.

I don't really want to be included in this discussion so please exclude me 
from any replies, I can read replies on the list but don't want my mailbox 
flooded with this thread. I could (and probably should) stay out of it but 
maybe can offer some outsider view and share a suggestion.

I haven't followed all this thread but if your problem with it is that 
something called malta should emulate that machine and not something 
non-existent "malta-unleashed" then how about introducing a new machine 
called virt which is a purely virtual machine? Arm has such a machine and 
is recommended to be used for those who just want a generic Linux machine 
without emulating any particular hardware. See here in docs:

https://wiki.qemu.org/Documentation/Platforms/ARM#Guidelines_for_choosing_a_QEMU_machine

I think Philippe was probably trying to do something like that with this 
series which is clearly not forbidden by any QEMU policy as evidenced by 
arm virt so maybe it's only a disagreement about how this should be named.

Keep malta to be modeling the Malta machine and add a new one called virt 
which can be a copy of the current malta initially just to start from 
somewhere (as arm was using versatilepb as mentioned above) but then the 
directions these machines will be developed further could be different: 
Malta would be developed to faithfully model the Malta machine, running 
its firmware, etc. while virt could allow having more RAM or virtio 
devices not available on real hardware. Why is that not acceptable?

Regards,
BALATON Zoltan

> Regards,
> Aleksandar
>
>
> уто, 30. јун 2020. у 21:58 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).
>>
>> Since v2:
>> - Initialize missing malta_machine_types::class_size
>> - Remove RFC patch that confuses Aleksandar
>> - Added examples of 'malta-strict' use
>>
>> $ git backport-diff -u v2
>> Key:
>> [----] : patches are identical
>> [####] : number of functional differences between upstream/downstream patch
>> [down] : patch is downstream-only
>> The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
>>
>> 001/5:[----] [--] 'hw/mips/malta: Trivial code movement'
>> 002/5:[----] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
>> 003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
>> 004/5:[----] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
>> 005/5:[----] [--] 'hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes'
>>
>> Philippe Mathieu-Daudé (5):
>>   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.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
>>  1 file changed, 91 insertions(+), 14 deletions(-)
>>
>> --
>> 2.21.3
>>
>>
>
>

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

[Aurelien Jarno]

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

Aleksandar,

On 2020-06-30 23:54, Aleksandar Markovic wrote:
> As, in a very clear way, evidenced from the previous versions of this
> series, this series real goal was not not to create some new
> "malta-strict" machine, but to prepare path to creation of some
> imagined "malta-unleashed" machine which will, to the contrary of
> proclaimed goal, create a machine that could never exist in reality.
> That is why I can't accept this series.

I do not understand your opposition to this, and why it is an issue to
support more than 2GiB of RAM for such a board. Supporting more than 2GiB
of memory doesn't prevent people to emulate a real Malta board with less
memory.

In addition to that, the Malta board in QEMU has been supporting for
many years more than the maximum 256MiB that is possible on a physical
board. The QEMU version also supports way more than CPU variants than
the physical board. In other word the existing malta machine in QEMU is
already a "malta-unleashed".

And these possibilities have been used by MIPS* employees to develop
MIPS R6 based distributions. Limiting the board in terms of RAM, CPU or
virtio support would just make our users life more difficult for no
gain.

Regards,
Aurelien

* By MIPS employee, I mean persons that have been employed by companies
owning MIPS over the last few years, including Imagination Technologies
and Wave Computing.



> уто, 30. јун 2020. у 21:58 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).
> >
> > Since v2:
> > - Initialize missing malta_machine_types::class_size
> > - Remove RFC patch that confuses Aleksandar
> > - Added examples of 'malta-strict' use
> >
> > $ git backport-diff -u v2
> > Key:
> > [----] : patches are identical
> > [####] : number of functional differences between upstream/downstream patch
> > [down] : patch is downstream-only
> > The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
> >
> > 001/5:[----] [--] 'hw/mips/malta: Trivial code movement'
> > 002/5:[----] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
> > 003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
> > 004/5:[----] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
> > 005/5:[----] [--] 'hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes'
> >
> > Philippe Mathieu-Daudé (5):
> >   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.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
> >  1 file changed, 91 insertions(+), 14 deletions(-)
> >
> > --
> > 2.21.3
> >
> >
> 

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Aleksandar Markovic]

On Wed, Jul 1, 2020 at 7:39 PM Aurelien Jarno <aurelien@aurel32.net> wrote:
>
> Aleksandar,
>
> On 2020-06-30 23:54, Aleksandar Markovic wrote:
> > As, in a very clear way, evidenced from the previous versions of this
> > series, this series real goal was not not to create some new
> > "malta-strict" machine, but to prepare path to creation of some
> > imagined "malta-unleashed" machine which will, to the contrary of
> > proclaimed goal, create a machine that could never exist in reality.
> > That is why I can't accept this series.
>
> I do not understand your opposition to this, and why it is an issue to
> support more than 2GiB of RAM for such a board. Supporting more than 2GiB
> of memory doesn't prevent people to emulate a real Malta board with less
> memory.
>
> In addition to that, the Malta board in QEMU has been supporting for
> many years more than the maximum 256MiB that is possible on a physical
> board. The QEMU version also supports way more than CPU variants than
> the physical board. In other word the existing malta machine in QEMU is
> already a "malta-unleashed".
>

Aurelien,

Glad to see you again. I am really sorry you were absent for so long.

Those (what you described in the paragraphs above) were mistakes from
the past. At some point, we needed to stop doing it, and finally
returned to the root QEMU principles of emulating systems as
faithfully as possible.

Knowing the needs like you described exist, my vision is that, just
for occasions you described, we create a virtual board that would have
very wide set of feature, unconstrained by real world. That way we
would avoid situations to "lie" in our emulations.

If you needed something more that is currently provided, you should
have issued a feature request through regular channels, and that would
have the people the chance to develop a solid solution, not some quick
fixes that pushes us further and further in wring direction.

Best wishes,
Aleksandar


Why didn't you respond on my mail from the other day? Do you plan to respond?

> And these possibilities have been used by MIPS* employees to develop
> MIPS R6 based distributions. Limiting the board in terms of RAM, CPU or
> virtio support would just make our users life more difficult for no
> gain.
>
> Regards,
> Aurelien
>
> * By MIPS employee, I mean persons that have been employed by companies
> owning MIPS over the last few years, including Imagination Technologies
> and Wave Computing.
>
>
>
> > уто, 30. јун 2020. у 21:58 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).
> > >
> > > Since v2:
> > > - Initialize missing malta_machine_types::class_size
> > > - Remove RFC patch that confuses Aleksandar
> > > - Added examples of 'malta-strict' use
> > >
> > > $ git backport-diff -u v2
> > > Key:
> > > [----] : patches are identical
> > > [####] : number of functional differences between upstream/downstream patch
> > > [down] : patch is downstream-only
> > > The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
> > >
> > > 001/5:[----] [--] 'hw/mips/malta: Trivial code movement'
> > > 002/5:[----] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
> > > 003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
> > > 004/5:[----] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
> > > 005/5:[----] [--] 'hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes'
> > >
> > > Philippe Mathieu-Daudé (5):
> > >   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.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
> > >  1 file changed, 91 insertions(+), 14 deletions(-)
> > >
> > > --
> > > 2.21.3
> > >
> > >
> >
>
> --
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                 http://www.aurel32.net

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

[Aurelien Jarno]

Aleksandar,

On 2020-07-01 20:51, Aleksandar Markovic wrote:
> On Wed, Jul 1, 2020 at 7:39 PM Aurelien Jarno <aurelien@aurel32.net> wrote:
> >
> > Aleksandar,
> >
> > On 2020-06-30 23:54, Aleksandar Markovic wrote:
> > > As, in a very clear way, evidenced from the previous versions of this
> > > series, this series real goal was not not to create some new
> > > "malta-strict" machine, but to prepare path to creation of some
> > > imagined "malta-unleashed" machine which will, to the contrary of
> > > proclaimed goal, create a machine that could never exist in reality.
> > > That is why I can't accept this series.
> >
> > I do not understand your opposition to this, and why it is an issue to
> > support more than 2GiB of RAM for such a board. Supporting more than 2GiB
> > of memory doesn't prevent people to emulate a real Malta board with less
> > memory.
> >
> > In addition to that, the Malta board in QEMU has been supporting for
> > many years more than the maximum 256MiB that is possible on a physical
> > board. The QEMU version also supports way more than CPU variants than
> > the physical board. In other word the existing malta machine in QEMU is
> > already a "malta-unleashed".
> >
> 
> Aurelien,
> 
> Glad to see you again. I am really sorry you were absent for so long.

I assumed that since haven't dramatically changes in QEMU since I left,
however if I missed some recent discussions that goes again what I am
saying below, please feel free to point me to them.

> Those (what you described in the paragraphs above) were mistakes from
> the past. At some point, we needed to stop doing it, and finally
> returned to the root QEMU principles of emulating systems as
> faithfully as possible.

I think there is a big misunderstanding here. The root QEMU principle is
to emulate each *device* or *feature* as faithfully as possible. The
*default* system that is emulated should also match as much as possible
the real hardware, but QEMU also gives users the possibility to create a
system as they want. And the amount of memory is one them.  That's
actually all the beauty of QEMU. Remember that QEMU solely exists
because it has users, and that the possibility to extend the RAM of the
Malta board to 2GB and to select various CPUs is widely used by users.

So overall there are plenty of counter examples to your "root QEMU
principles". Daniel P. Berrangé mentioned the memory support on the
i440fx x86 hardware. As other examples you can also add AMD 3D Now
instructions to an Intel CPU, or add an AC97 sound device to a SH4
machine. Virtio is another example.

> Knowing the needs like you described exist, my vision is that, just
> for occasions you described, we create a virtual board that would have
> very wide set of feature, unconstrained by real world. That way we
> would avoid situations to "lie" in our emulations.

Adding a "virt" machine like it has been done on some other
architectures is probably a good idea to give users even more
possibilities. Now I do not believe its a reason to not allow users to
slightly extend an existing system.

In addition to that, creating a new virt machine and getting it fully
usable is a multi year project. In addition to the QEMU changes, you
also need to get kernel and bootloader support. And then it has to reach
the distributions.

> If you needed something more that is currently provided, you should
> have issued a feature request through regular channels, and that would
> have the people the chance to develop a solid solution, not some quick
> fixes that pushes us further and further in wring direction.

QEMU doesn't have an upstream bug tracker, so I guess that regular
channels basically mean the mailing list. I therefore express the need
for a MIPS "virt" machine that supports more than 2GB. Please ping me
when it's ready.

Best regards,
Aurelien

> Why didn't you respond on my mail from the other day? Do you plan to respond?

I just responded to it, overall in less than 12 hours.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

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

[Thomas Huth]

On 01/07/2020 23.17, Aurelien Jarno wrote:
> Aleksandar,
> 
> On 2020-07-01 20:51, Aleksandar Markovic wrote:
>> On Wed, Jul 1, 2020 at 7:39 PM Aurelien Jarno <aurelien@aurel32.net> wrote:
>>>
>>> Aleksandar,
>>>
>>> On 2020-06-30 23:54, Aleksandar Markovic wrote:
>>>> As, in a very clear way, evidenced from the previous versions of this
>>>> series, this series real goal was not not to create some new
>>>> "malta-strict" machine, but to prepare path to creation of some
>>>> imagined "malta-unleashed" machine which will, to the contrary of
>>>> proclaimed goal, create a machine that could never exist in reality.
>>>> That is why I can't accept this series.
>>>
>>> I do not understand your opposition to this, and why it is an issue to
>>> support more than 2GiB of RAM for such a board. Supporting more than 2GiB
>>> of memory doesn't prevent people to emulate a real Malta board with less
>>> memory.
>>>
>>> In addition to that, the Malta board in QEMU has been supporting for
>>> many years more than the maximum 256MiB that is possible on a physical
>>> board. The QEMU version also supports way more than CPU variants than
>>> the physical board. In other word the existing malta machine in QEMU is
>>> already a "malta-unleashed".
>>>
>>
>> Aurelien,
>>
>> Glad to see you again. I am really sorry you were absent for so long.
> 
> I assumed that since haven't dramatically changes in QEMU since I left,
> however if I missed some recent discussions that goes again what I am
> saying below, please feel free to point me to them.
> 
>> Those (what you described in the paragraphs above) were mistakes from
>> the past. At some point, we needed to stop doing it, and finally
>> returned to the root QEMU principles of emulating systems as
>> faithfully as possible.
> 
> I think there is a big misunderstanding here. The root QEMU principle is
> to emulate each *device* or *feature* as faithfully as possible. The
> *default* system that is emulated should also match as much as possible
> the real hardware, but QEMU also gives users the possibility to create a
> system as they want. And the amount of memory is one them.  That's
> actually all the beauty of QEMU. Remember that QEMU solely exists
> because it has users, and that the possibility to extend the RAM of the
> Malta board to 2GB and to select various CPUs is widely used by users.
> 
> So overall there are plenty of counter examples to your "root QEMU
> principles". Daniel P. Berrangé mentioned the memory support on the
> i440fx x86 hardware. As other examples you can also add AMD 3D Now
> instructions to an Intel CPU, or add an AC97 sound device to a SH4
> machine. Virtio is another example.

I fully agree with Aurelien and Daniel here. As far as I know, there has 
never been a "root QEMU principle" that says that we have to restrict 
things like RAM sizes to the constraints of real hardware.

Aleksandar, where did you get the idea of that "root QEMU principle" 
from? If it's something that is written in our documentation somewhere, 
it's maybe misleading and needs to be rewritten, so please provide a 
pointer.

  Thanks,
   Thomas

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

[Jiaxun Yang]

在 2020/7/1 3:57, 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).


Just putting my random words here as things had became really tense..

My orginal proposal was served to some occational case.

Yunqiang said sometimes he will run memory intensives task in QEMU, and 
found 2G memory limitation had became the bottle neck of these usage. At 
that time I was trying to learn how QEMU work, so I made that patch to 
convinient him. Also submited it to upstream as I think it can 
convinient others as well.

I was thinking the fundmental reason of QEMU's extistence is to make 
people's life easier. With QEMU, one can test OS/application without own 
actaul hardware or limited by unreasonable hardware design. That's why I 
was trying to upstream that change.

If we're looking for accurate hardware emulator, probably we should ask 
for RTL code from manufactures and run it in iverilog.

Anyway, as a hobbist, I'm really graceful to what have done by 
Alexsandar in maintaining QEMU/MIPS. The future of MIPS is really 
unclear due to commerical reasons. I just don't want to see MIPS being 
threw away by the community as soon as the business collapse.

Thanks


~Jiaxun


>
> Since v2:
> - Initialize missing malta_machine_types::class_size
> - Remove RFC patch that confuses Aleksandar
> - Added examples of 'malta-strict' use
>
> $ git backport-diff -u v2
> Key:
> [----] : patches are identical
> [####] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
>
> 001/5:[----] [--] 'hw/mips/malta: Trivial code movement'
> 002/5:[----] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
> 003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
> 004/5:[----] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
> 005/5:[----] [--] 'hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes'
>
> Philippe Mathieu-Daudé (5):
>    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.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
>   1 file changed, 91 insertions(+), 14 deletions(-)
>