qemu-trivial
[Top][All Lists]
Advanced

[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: Aurelien Jarno
Subject: Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
Date: Wed, 1 Jul 2020 23:17:03 +0200
User-agent: Mutt/1.14.0 (2020-05-02)

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



reply via email to

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