On 30/06/2020 13.17, Aleksandar Markovic wrote:
уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4...@amsat.org
<mailto:f4...@amsat.org>> је написао/ла:
On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
>
>
> уторак, 30. јун 2020., Philippe Mathieu-Daudé <f4...@amsat.org
<mailto:f4...@amsat.org>
> <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> је написао/ла:
>
> On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> <f4...@amsat.org <mailto:f4...@amsat.org>
<mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> wrote:
> >
> > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
<f4...@amsat.org <mailto:f4...@amsat.org>
> <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>
> > > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>
<mailto:f4...@amsat.org <mailto:f4...@amsat.org>>>> је написао/ла:
> > >
> > > Hi,
> > >
> > > Following Jiaxun Yang's patch and discussion:
> > > https://patchwork.kernel.org/patch/11416915/
<https://patchwork.kernel.org/patch/11416915/>
> <https://patchwork.kernel.org/patch/11416915/
<https://patchwork.kernel.org/patch/11416915/>>
> > > <https://patchwork.kernel.org/patch/11416915/
<https://patchwork.kernel.org/patch/11416915/>
> <https://patchwork.kernel.org/patch/11416915/
<https://patchwork.kernel.org/patch/11416915/>>>
> > >
> > > - Rename the current machine as 'malta-virt' (keeping
> 'malta' aliased)
> > > Suggestions for better names are welcome, maybe
> 'malta-unreal' or
> > > 'malta-unleashed' instead?
> > > - Add 'malta-phys' which respects hardware
restrictions (on
> RAM so far)
> > > - Unleash 'malta-virt' to allow more than 2GB on 64-bit
> > >
> > > Philippe Mathieu-Daudé (7):
> > > hw/mips/malta: Trivial code movement
> > > hw/mips/malta: Register the machine as a TypeInfo
> > > hw/mips/malta: Rename 'malta' machine as 'malta-virt'
> > > hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> > > hw/mips/malta: Introduce the 'malta-phys' machine
> > > hw/mips/malta: Verify malta-phys machine uses
correct DIMM
> sizes
> > > hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
> > >
> > > hw/mips/malta.c | 121
> +++++++++++++++++++++++++++++++++++++++---------
> > > 1 file changed, 99 insertions(+), 22 deletions(-)
> > >
> > > --
> > >
> > >
> > >
> > > Thank you, Philippe, for providing this series.
> > >
> > > However, in previous discussion on the patch you mention
above, I
> > > already expressed serious reservations on the approach
taken in that
> > > patch. These reservations stay today too.
> > >
> > > There is nothing qualitatively different between the original
> patch and
> > > this series. Naming and related stuff are just cosmetic
issues.
> >
> > OK, what about considering all patches except the last one?
> > So we can run firmware on a real Malta board, not the QEMU
> > imaginary one (in the discussion you said QEMU should respect
> > real hardware, which I agree).
> >
> > >
> > > The good thing about this series is that one can apply it
> dowstream, if
> > > one finds it useful. However, it is not suitable for
upstreaming
>
> IOW, what is missing to have this series (except the last patch)
> accepted upstream?
>
>
> It is not what is missing, but was already is in the series that
makes
> it not suitable for upstreaming. The very concept of the series is
> problematic.
What is the series is not suitable for upstream? Can you point to
patch and code please? How would you conceptually resolve the
problem?
The answer is already in the original thread on the original patch.
The problem is artificialy imposed:
One needs a feature not present in the physical system. The solution is
not in creating "virtual" upgrade - this violates the basic foundation
if QEMU.
If the feature is missing, the optimal solution would be emulating the
physical solution that has that feature.
In some rare cases (that should be avoided as mush as possible), and for
really good reasons, we can create an emulation of some imagined
hardware that was never designed let alone built - there are a couple of
examples in other targets.
But extending the emulation of existing physical system with
non-existing features is not acceptable.
Interesting statement. I suggest to include the following patch in your
next mips pull request to avoid that mips users spoil their machines
with virtual-only features:
diff a/default-configs/mips-softmmu-common.mak
b/default-configs/mips-softmmu-common.mak
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -6,10 +6,10 @@ CONFIG_SEMIHOSTING=y
CONFIG_ISA_BUS=y
CONFIG_PCI=y
CONFIG_PCI_DEVICES=y
+CONFIG_VIRTIO_PCI=n
CONFIG_VGA_ISA=y
CONFIG_VGA_ISA_MM=y
CONFIG_VGA_CIRRUS=y
-CONFIG_VMWARE_VGA=y
CONFIG_SERIAL=y
CONFIG_SERIAL_ISA=y
CONFIG_PARALLEL=y
;-)
No, seriously, as far as I can tell, QEMU was never in that "we strictly
only emulate real hardware" camp, even the homepage talks about
"virtualizer".
But introducing a separate machine for this feature sounds a little bit
excessive for me, too. What about introducing a machine property for the
max-ram-size? With the default value, the machine could restrict the ram
sizes to the values that are possible with the real hardware, and only
if the (advanced) user tweaks the property, it would be possible to set
bigger values. Just my 0.02 €.
Thomas
PS: Why does mips use CONFIG_VMWARE_VGA=y at all? Is VMWARE also
available for mips?
PPS: Why is mips still not using proper Kconfig settings yet?
