[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Huth
Subject: Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
Date: Thu, 2 Jul 2020 09:45:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 01/07/2020 23.17, Aurelien Jarno wrote:

On 2020-07-01 20:51, Aleksandar Markovic wrote:
On Wed, Jul 1, 2020 at 7:39 PM Aurelien Jarno <aurelien@aurel32.net> wrote:


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

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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]