Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
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 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
Aleksandar, On 2020-07-01 20:51, Aleksandar Markovic wrote: > On Wed, Jul 1, 2020 at 7:39 PM Aurelien Jarno 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 aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
On Wed, Jul 1, 2020 at 7:39 PM Aurelien Jarno 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é је > > написао/ла: > > > > > > 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 > aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
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é је > написао/ла: > > > > 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 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
在 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
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é је написао/ла: 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
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é је написао/ла: > > 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 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware
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