On 22/01/2023 22:07, BALATON Zoltan wrote:
> On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
>> On 12/01/2023 23:51, BALATON Zoltan wrote:
>>> On Thu, 12 Jan 2023, Howard Spoelstra wrote:
>>>> On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>>>>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>>>>>> Setting emulated machine type with a property called "via" is
>>>>>>> confusing users so deprecate the "via" option in favour of newly added
>>>>>>> explicit machine types. The default via=cuda option is not a valid
>>>>>>> config (no real Mac has this combination of hardware) so no machine
>>>>>>> type could be defined for that therefore it is kept for backwards
>>>>>>> compatibility with older QEMU versions for now but other options
>>>>>>> resembling real machines are deprecated.
>>>>>>>
>>>>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>>>>
>>>>>> I believe that people do use -M mac99,via=cuda to run some rare versions
>>>>> of
>>>>>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we
>>>>> would
>>>>>> want to keep this option somewhere.
>>>>>
>>>>> The idea is that after previous patches we now have machine types for all
>>>>> other via option values (that also match real Mac machines) other than
>>>>> via=cude but that is the default for mac99 so after the reprecation period
>>>>> when the via option is removed mac99 (which is the same as mac99,via=cuda)
>>>>> can remain for this use case (and for backward compatibility) until the
>>>>> other machines are fixed to not need this any more. So all via options are
>>>>> still available but as different machine types.
>>>>>
>>>> My 2 cents about naming:
>>>> It seems less important how the machines are named when their name is not
>>>> covering their definition. F.i. the powermac3,1 never had adb, could not be
>>>> equipped with a G3 cpu, did not run at 900Mhz. The closest possible
>>>> qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac
>>>> OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is
>>>> already needed.
>>>
>>> What does that mean? Should we aim to emulate real Macs or are we happy with the
>>> Franken-Mac we have now? The names also show what we intend to emulate even though
>>> the emulation may not be complete or have bugs (this is also true for other
>>> machines in QEMU where a lot of them are not fully emulated, only well enough to
>>> boot guest OSes).
>>>
>>> Looks like everybody has forgotten the previous discussion and not read the docs
>>> and deprecation patches where this is explained so I summarise the proposed change
>>> here again:
>>>
>>> - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for
>>> the via option and when using it in qemu-system-ppc64 suggesting using new
>>> machines instead so these could evetually be removed next year. mac99,via=cuda is
>>> just mac99 so you can continue to use that, mac99 is not deprecated and don't want
>>> to remove it.
>>>
>>> - qemu-system-ppc64 -M mac99 -> powermac7_3
>>>
>>> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1
>>>
>>> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2
FWIW this information would be useful in the cover letter once we decide the way
forward. Also as a reviewer, it is hard to keep track of all the changes if the
series are constantly changing and with no changelog on the cover letter, which is
why it takes me a while to review them.
>>> The last one is one of the rare Macs that had adb and pmu, all others with pmu
>>> usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware
>>> but more similar to g3beige and no ADB ports according to
>>> https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite
>>> https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware
>>>
>>> The PowerMac7,3 seems to be matching the PCI device listing in the comment at the
>>> beginning of mac_newworld.c and also this article:
>>> https://www.informit.com/articles/article.aspx?p=606582
>>>
>>> What is the 2 USB devices problem? Is it the one we've debugged before and found
>>> that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be
>>> fixed if there was somebody interested enough to provide a patch.
>>>
>>> But this series does not remove the mac99 and does not even deprecate it. What it
>>> deprecates are the via option to select different machine types and the automatic
>>> detection of ppc64 to emulate something different which are hard to understand for
>>> users and caused several misunderstandings. It's much more clear to have a
>>> separate machine type for each machine we emulate even when they aren't yet
>>> complete but at least we know which way to go and can compare to real hardware and
>>> fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99
>>> would allow to remove qemu-system-ppc if we wanted and only have one executable
>>> for all machines but even without this it's clearer to have separate machnies for
>>> G5 and G4 macs than mac99 silently behaving differently.
>>
>> Ultimately the issue you are trying to solve is this, which is that -M mac99 is
>> different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way to start
>> is to create a new "g5niagara" machine type (including OpenBIOS) and make it a
>> clone of mac_newworld.c, and then issue a warning on qemu-system-ppc64 for -M mac99.
>
> I don't get what you mean. Patch 4 introduces a new machine type called powermac7_3
> (or g5niagara if you want) which is a clone of mac99 and then issues the warning to
> deprecate qemu-system-ppc64 -M mac99 in patch 5. Did you actually test these patches
> at all?
More specifically, what I'm suggesting as well as creating a new machine name is that
we clone mac_newworld.c into a separate file for the 64-bit Mac machine, declare it
as compiled for PPC64 only, and put the deprecation there. By creating a separate
file and separate machine type for OpenBIOS, it gives you the freedom to make changes
to mac99 to move it towards a G4 AGP without having to worry about affecting any
existing 64-bit users.
>> The reason for suggesting this is that the number of users of qemu-system-ppc64 -M
>> mac99 will be much smaller than those using qemu-system-ppc, which means there will
>> be a lot less breakage for users. In
>
> Except those who mean to use ppc mac99 but think that they should use
> qemu-system-ppc64 on 64 bit Windows which is probably the highest number of users
> currently. I've cc'd you on the last instance of this but can dig up some more from
> last year and look at the emaculation.com forum or ask Howard how many times that
> happens. So after these patches users can still use qemu-system-ppc -M mac99 as
> before without a warning but will get warned for qemu-system-ppc64 -M mac99 to use
> powernac7_3 instead.
We're saying the same thing here, no?
>> the meantime we don't need to make a final decision re: machine names, yet it still
>> gives you the freedom to work on -M mac99 for 32-bit Macs and move it closer
>> towards the G4 AGP model.
>
> That's a different issue you're mixing in here. One issue is mac99 emulating
> different machines with ppc and pcc64, this is solved as above. Another issue is that
> ppc mac99 is not a real mac, to get the hardware to match the device tree OpenBIOS
> tells the guest it is you have to use mac99,via=pmu which no user can guess. I want
> to rename this to simply powermac3_1 and get rid of the via option eventually and
> make these separate machines which is much more clear to the user. The implementation
> remains the same, but we're free to change that later once the naming is resolved. So
> I think we should decide on naming now and start deprecating old names (which are
> ppc64 mac99 and macc99 with via option so we only leave mac99 as before and all other
> variants will become -machine options). What part of this is not clear to you. I feel
> like despite trying to explain it for the third time we're still not on the same page.
The default was set to mac99,via=cuda since that was the original implementation and
via=pmu broke booting some images (unfortunately I can't remember the detail right
now). Ultimately my aim was to fix the remaining bugs and switch the mac99 default to
via=pmu, but due to various changes in the past couple of years my available time to
work on QEMU is considerably reduced.
From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due to the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be that these suffer the same usb issue)
The real powermac3,1 AGP has no adb.
via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only needed for Mac OS X 10.5 guest (for which the speed reported was hacked to 900Mhz to fool the installer), but should support all Mac OS/OS X that are now supported.
via=pmu-adb seems only needed to trick mac os server installations that would later run on the g3beige.
To my knowledge 32 bit Linux guests all require via=pmu
Best,
Howard
What I see you are effectively asking for is a new machine which is currently
equivalent to -M mac99,via=pmu that you wish to diverge towards a real G4 AGP
machine, right?
ATB,
Mark.