On Sat, 29 Oct 2022, Mark Cave-Ayland wrote:
On 28/10/2022 13:18, BALATON Zoltan wrote:
On Fri, 28 Oct 2022, Mark Cave-Ayland wrote:
On 25/10/2022 17:44, BALATON Zoltan wrote:
The mac99 machine emulates different machines depending on machine
properties or even if it is run as qemu-system-ppc64 or
qemu-system-ppc. This is very confusing for users and many hours were
lost trying to explain it or finding out why commands users came up
with are not working as expected. (E.g. Windows users might think
qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and
then fail to boot a 32 bit OS with -M mac99 trying to follow an
example that had qemu-system-ppc.) To avoid such confusion, add
explicit machine types for the different configs which will work the
same with both qemu-system-ppc and qemu-system-ppc64 and also make the
command line clearer for new users.
What was the outcome of the discussion re: having separate machines for
32-bit and 64-bit PPC targets? My understanding is the issue here was
deciding what to do, rather than actually making the code changes.
Who do you think will or should decide about this? There are about 3 people
who care about Mac emulation on this list: you, Howard and me. You already
have my and Howard's vote to introduce these machines types. Who else
should vote or decide on this? Please apply this patch now and if it causes
problem it can still be dropped duting the freeze but if you don't apply it
now it can't get into before next spring.
This is not restricted to qemu-system-ppc though: there was a discussion
(which was still ongoing) as to how all of QEMU should handle 32-bit and
64-bit machines i.e. should qemu-system-ppc64 only contain 64-bit machines
and qemu-system-ppc only contain 32-bit machines? If we wish to make a change
here, we should wait for the outcome of this to ensure consistency here.
That's unrelated to mac99 then so we can sort that out independently now
as this will be needed anyway to remove the confusing behaviour of mac99
emulating different machines depending if it's part of qemu-system-ppc or
qemu-system-ppc64. Whatever the decision with 32 vs 64 bit will be this
will have to go so better deprecate it now so we can more easily adapt
whatever that decision will be (if it will have a decision in the near
fututre at all). I don't think that's a good reason to ditch this patch as
I don't see this is getting to a decision soon which would need doing else
than deprecating mac99.
Also what was your motivation for choosing the machine names? I see you've
used powerbook for via=pmu-adb, but I think quite a few people use pmu-adb
for older OS X server hardware. At the very least some pointers to
reference device trees and some rationale behind the decision is needed
for review.
See my reply to Howard's message with some more info and links. My
immediate motivation was that we've lost about two days when somobody
contacted me about VGA pass through sending logs about all kinds of
failures he got. After many logs I've noticed that he was using
qemu-system-ppc64 -M mac99,via=pmu thinking that on 64bit host that's the
executable he should use. Unfortunately the commands were not shared just
the logs so this took a while to notice. Also if you look at the forum
Howard runs you can see this problem is coming up frequently and I think
the've also lost countless hours due to this. It's about time to put an end
on it and stop wasting othet's time. As for The machines, the powermac ones
are straight forward as those are closest to what we emulate for G4 and G5
Mac. I've chosen the powerbook becuase that's the only machine I know that
had PMU and ADB but If someone knows a better machine we can change this
(even as bug fix during the freeze). Here's some info on this powerbook:
https://ppc.0penbsd.narkive.com/s49Kcx1u/x-on-powerbook-g4
In all my time working on QEMU this has happened to me once: yes, I agree it
can be annoying but given how rare it happens I don't see a need to make a
rushed decision now.
Maybe because you don't work with users like Howard or don't work with
ati-vga like me. But we got this problem many times, I've got bitten by
forgetting the vga-ndrv? option several times and had to remember this is
breaking stuff so that this works for you is no reason to believe it's not
causing problems for anybody. A better approach may be if a proposed
solution is not breaking anything for you then accept it rather than
having the basic view of resisting any change from anywhere. As a private
developer you can so that but as a maintainer you should not lock out
others from contributing and be more accepting or other solutions.
In terms of choosing the machines for QEMU we will need a full copy of the DT
from real hardware for comparison with OpenBIOS, and ideally a Linux dmesg.
I don't use that pmu-adb config and I think maybe we don't even need it
once USB emulation is fixed on powermac3_1 as those OSes should support
powermac3_1 or g3beige so I'm OK with dropping this powerbook machine for
now and only merging the powermac3_1 and powermac7_3 machines which I care
more about. Can you change the patches accordingly before merge or you
want me to submit another version with this chnage? You could also take
the first 14 patches if you're OK with them now so I have to resend less.
Regards,
BALATON Zoltan
