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

Philippe Mathieu-Daudé posted 5 patches 3 years, 9 months ago
Test FreeBSD passed
Test docker-quick@centos7 passed
Test checkpatch passed
Test docker-mingw@fedora passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20200630195723.1359-1-f4bug@amsat.org
Maintainers: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>, Laurent Vivier <laurent@vivier.eu>, Aurelien Jarno <aurelien@aurel32.net>, Michael Tokarev <mjt@tls.msk.ru>, Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
hw/mips/malta.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 91 insertions(+), 14 deletions(-)
[PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
Posted by Philippe Mathieu-Daudé 3 years, 9 months ago
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
Posted by Jiaxun Yang 3 years, 9 months ago
在 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(-)
>

Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
Posted by Aleksandar Markovic 3 years, 9 months ago
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
Posted by BALATON Zoltan 3 years, 9 months ago
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
Posted by Aurelien Jarno 3 years, 9 months ago
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
Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
Posted by Aleksandar Markovic 3 years, 9 months ago
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
Posted by Aurelien Jarno 3 years, 9 months ago
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
Posted by Thomas Huth 3 years, 9 months ago
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