[PATCH v7 0/7] Misc ppc/mac machines clean up

[PATCH v7 0/7] Misc ppc/mac machines clean up

[BALATON Zoltan]

This is the remainder of the series that were postponed to after the
freeze the last time I've tried to submit them with some new patches
I did meanwhile.

BALATON Zoltan (7):
  input/adb: Only include header where needed
  mac_{old,new}world: Use local variable instead of qdev_get_machine()
  mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
  mac_newworld: Add machine types for different mac99 configs
  mac_newworld: Deprecate mac99 with G5 CPU
  mac_newworld: Deprecate mac99 "via" option
  mac_newworld: Document deprecation

 docs/about/deprecated.rst    |   7 ++
 docs/system/ppc/powermac.rst |  12 ++--
 hw/misc/macio/cuda.c         |   2 -
 hw/misc/macio/pmu.c          |   3 -
 hw/misc/mos6522.c            |   1 -
 hw/ppc/mac_newworld.c        | 130 +++++++++++++++++++++++++++++++----
 hw/ppc/mac_oldworld.c        |  21 ++----
 include/hw/misc/mac_via.h    |   1 +
 include/hw/misc/macio/cuda.h |   1 +
 include/hw/misc/macio/pmu.h  |   1 +
 include/hw/misc/mos6522.h    |   3 +-
 11 files changed, 142 insertions(+), 40 deletions(-)

-- 
2.30.6

[PATCH v7 1/7] input/adb: Only include header where needed

[BALATON Zoltan]

The header hw/input/adb.h is included by some files that don't need
it. Clean it up and include only where necessary.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
 hw/misc/macio/cuda.c         | 2 --
 hw/misc/macio/pmu.c          | 3 ---
 hw/misc/mos6522.c            | 1 -
 include/hw/misc/mac_via.h    | 1 +
 include/hw/misc/macio/cuda.h | 1 +
 include/hw/misc/macio/pmu.h  | 1 +
 include/hw/misc/mos6522.h    | 3 +--
 7 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index 853e88bfed..7208b90e12 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -27,8 +27,6 @@
 #include "hw/irq.h"
 #include "hw/qdev-properties.h"
 #include "migration/vmstate.h"
-#include "hw/input/adb.h"
-#include "hw/misc/mos6522.h"
 #include "hw/misc/macio/cuda.h"
 #include "qapi/error.h"
 #include "qemu/timer.h"
diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
index 97ef8c771b..8575bc1264 100644
--- a/hw/misc/macio/pmu.c
+++ b/hw/misc/macio/pmu.c
@@ -31,10 +31,7 @@
 #include "qemu/osdep.h"
 #include "hw/qdev-properties.h"
 #include "migration/vmstate.h"
-#include "hw/input/adb.h"
 #include "hw/irq.h"
-#include "hw/misc/mos6522.h"
-#include "hw/misc/macio/gpio.h"
 #include "hw/misc/macio/pmu.h"
 #include "qapi/error.h"
 #include "qemu/timer.h"
diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
index 0ed631186c..d6ba47bde9 100644
--- a/hw/misc/mos6522.c
+++ b/hw/misc/mos6522.c
@@ -25,7 +25,6 @@
  */
 
 #include "qemu/osdep.h"
-#include "hw/input/adb.h"
 #include "hw/irq.h"
 #include "hw/misc/mos6522.h"
 #include "hw/qdev-properties.h"
diff --git a/include/hw/misc/mac_via.h b/include/hw/misc/mac_via.h
index 5fe7a7f592..422da43bf9 100644
--- a/include/hw/misc/mac_via.h
+++ b/include/hw/misc/mac_via.h
@@ -12,6 +12,7 @@
 #include "exec/memory.h"
 #include "hw/sysbus.h"
 #include "hw/misc/mos6522.h"
+#include "hw/input/adb.h"
 #include "qom/object.h"
 
 
diff --git a/include/hw/misc/macio/cuda.h b/include/hw/misc/macio/cuda.h
index a71deec968..8a6678c749 100644
--- a/include/hw/misc/macio/cuda.h
+++ b/include/hw/misc/macio/cuda.h
@@ -26,6 +26,7 @@
 #ifndef CUDA_H
 #define CUDA_H
 
+#include "hw/input/adb.h"
 #include "hw/misc/mos6522.h"
 #include "qom/object.h"
 
diff --git a/include/hw/misc/macio/pmu.h b/include/hw/misc/macio/pmu.h
index 00fcdd23f5..ba76afb52a 100644
--- a/include/hw/misc/macio/pmu.h
+++ b/include/hw/misc/macio/pmu.h
@@ -10,6 +10,7 @@
 #ifndef PMU_H
 #define PMU_H
 
+#include "hw/input/adb.h"
 #include "hw/misc/mos6522.h"
 #include "hw/misc/macio/gpio.h"
 #include "qom/object.h"
diff --git a/include/hw/misc/mos6522.h b/include/hw/misc/mos6522.h
index 05872fffc9..fba45668ab 100644
--- a/include/hw/misc/mos6522.h
+++ b/include/hw/misc/mos6522.h
@@ -27,9 +27,8 @@
 #ifndef MOS6522_H
 #define MOS6522_H
 
-#include "exec/memory.h"
+#include "exec/hwaddr.h"
 #include "hw/sysbus.h"
-#include "hw/input/adb.h"
 #include "qom/object.h"
 
 #define MOS6522_NUM_REGS 16
-- 
2.30.6

Re: [PATCH v7 1/7] input/adb: Only include header where needed

[Philippe Mathieu-Daudé]

On 4/1/23 22:59, BALATON Zoltan wrote:
> The header hw/input/adb.h is included by some files that don't need
> it. Clean it up and include only where necessary.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>   hw/misc/macio/cuda.c         | 2 --
>   hw/misc/macio/pmu.c          | 3 ---
>   hw/misc/mos6522.c            | 1 -
>   include/hw/misc/mac_via.h    | 1 +
>   include/hw/misc/macio/cuda.h | 1 +
>   include/hw/misc/macio/pmu.h  | 1 +
>   include/hw/misc/mos6522.h    | 3 +--
>   7 files changed, 4 insertions(+), 8 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH v7 1/7] input/adb: Only include header where needed

[Mark Cave-Ayland]

On 04/01/2023 21:59, BALATON Zoltan wrote:

> The header hw/input/adb.h is included by some files that don't need
> it. Clean it up and include only where necessary.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>   hw/misc/macio/cuda.c         | 2 --
>   hw/misc/macio/pmu.c          | 3 ---
>   hw/misc/mos6522.c            | 1 -
>   include/hw/misc/mac_via.h    | 1 +
>   include/hw/misc/macio/cuda.h | 1 +
>   include/hw/misc/macio/pmu.h  | 1 +
>   include/hw/misc/mos6522.h    | 3 +--
>   7 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
> index 853e88bfed..7208b90e12 100644
> --- a/hw/misc/macio/cuda.c
> +++ b/hw/misc/macio/cuda.c
> @@ -27,8 +27,6 @@
>   #include "hw/irq.h"
>   #include "hw/qdev-properties.h"
>   #include "migration/vmstate.h"
> -#include "hw/input/adb.h"
> -#include "hw/misc/mos6522.h"
>   #include "hw/misc/macio/cuda.h"
>   #include "qapi/error.h"
>   #include "qemu/timer.h"
> diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
> index 97ef8c771b..8575bc1264 100644
> --- a/hw/misc/macio/pmu.c
> +++ b/hw/misc/macio/pmu.c
> @@ -31,10 +31,7 @@
>   #include "qemu/osdep.h"
>   #include "hw/qdev-properties.h"
>   #include "migration/vmstate.h"
> -#include "hw/input/adb.h"
>   #include "hw/irq.h"
> -#include "hw/misc/mos6522.h"
> -#include "hw/misc/macio/gpio.h"
>   #include "hw/misc/macio/pmu.h"
>   #include "qapi/error.h"
>   #include "qemu/timer.h"
> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
> index 0ed631186c..d6ba47bde9 100644
> --- a/hw/misc/mos6522.c
> +++ b/hw/misc/mos6522.c
> @@ -25,7 +25,6 @@
>    */
>   
>   #include "qemu/osdep.h"
> -#include "hw/input/adb.h"
>   #include "hw/irq.h"
>   #include "hw/misc/mos6522.h"
>   #include "hw/qdev-properties.h"
> diff --git a/include/hw/misc/mac_via.h b/include/hw/misc/mac_via.h
> index 5fe7a7f592..422da43bf9 100644
> --- a/include/hw/misc/mac_via.h
> +++ b/include/hw/misc/mac_via.h
> @@ -12,6 +12,7 @@
>   #include "exec/memory.h"
>   #include "hw/sysbus.h"
>   #include "hw/misc/mos6522.h"
> +#include "hw/input/adb.h"
>   #include "qom/object.h"
>   
>   
> diff --git a/include/hw/misc/macio/cuda.h b/include/hw/misc/macio/cuda.h
> index a71deec968..8a6678c749 100644
> --- a/include/hw/misc/macio/cuda.h
> +++ b/include/hw/misc/macio/cuda.h
> @@ -26,6 +26,7 @@
>   #ifndef CUDA_H
>   #define CUDA_H
>   
> +#include "hw/input/adb.h"
>   #include "hw/misc/mos6522.h"
>   #include "qom/object.h"
>   
> diff --git a/include/hw/misc/macio/pmu.h b/include/hw/misc/macio/pmu.h
> index 00fcdd23f5..ba76afb52a 100644
> --- a/include/hw/misc/macio/pmu.h
> +++ b/include/hw/misc/macio/pmu.h
> @@ -10,6 +10,7 @@
>   #ifndef PMU_H
>   #define PMU_H
>   
> +#include "hw/input/adb.h"
>   #include "hw/misc/mos6522.h"
>   #include "hw/misc/macio/gpio.h"
>   #include "qom/object.h"
> diff --git a/include/hw/misc/mos6522.h b/include/hw/misc/mos6522.h
> index 05872fffc9..fba45668ab 100644
> --- a/include/hw/misc/mos6522.h
> +++ b/include/hw/misc/mos6522.h
> @@ -27,9 +27,8 @@
>   #ifndef MOS6522_H
>   #define MOS6522_H
>   
> -#include "exec/memory.h"
> +#include "exec/hwaddr.h"
>   #include "hw/sysbus.h"
> -#include "hw/input/adb.h"
>   #include "qom/object.h"
>   
>   #define MOS6522_NUM_REGS 16

Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>


ATB,

Mark.

[PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine()

[BALATON Zoltan]

We already have machine in a local variable so no need to use
qdev_get_machine(), also remove now unneded line break.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
 hw/ppc/mac_newworld.c | 3 +--
 hw/ppc/mac_oldworld.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 601ea518f8..460c14b5e3 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -466,8 +466,7 @@ static void ppc_core99_init(MachineState *machine)
     fw_cfg = FW_CFG(dev);
     qdev_prop_set_uint32(dev, "data_width", 1);
     qdev_prop_set_bit(dev, "dma_enabled", false);
-    object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
-                              OBJECT(fw_cfg));
+    object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
     s = SYS_BUS_DEVICE(dev);
     sysbus_realize_and_unref(s, &error_fatal);
     sysbus_mmio_map(s, 0, CFG_ADDR);
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 558c639202..5a7b25a4a8 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -303,8 +303,7 @@ static void ppc_heathrow_init(MachineState *machine)
     fw_cfg = FW_CFG(dev);
     qdev_prop_set_uint32(dev, "data_width", 1);
     qdev_prop_set_bit(dev, "dma_enabled", false);
-    object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
-                              OBJECT(fw_cfg));
+    object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
     s = SYS_BUS_DEVICE(dev);
     sysbus_realize_and_unref(s, &error_fatal);
     sysbus_mmio_map(s, 0, CFG_ADDR);
-- 
2.30.6

Re: [PATCH v7 2/7] mac_{old, new}world: Use local variable instead of qdev_get_machine()

[Philippe Mathieu-Daudé]

On 4/1/23 22:59, BALATON Zoltan wrote:
> We already have machine in a local variable so no need to use
> qdev_get_machine(), also remove now unneded line break.

Typo "unneeded".

> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>   hw/ppc/mac_newworld.c | 3 +--
>   hw/ppc/mac_oldworld.c | 3 +--
>   2 files changed, 2 insertions(+), 4 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine()

[Bernhard Beschow]

Am 4. Januar 2023 21:59:37 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
>We already have machine in a local variable so no need to use
>qdev_get_machine(), also remove now unneded line break.
>
>Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>---
> hw/ppc/mac_newworld.c | 3 +--
> hw/ppc/mac_oldworld.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
>diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>index 601ea518f8..460c14b5e3 100644
>--- a/hw/ppc/mac_newworld.c
>+++ b/hw/ppc/mac_newworld.c
>@@ -466,8 +466,7 @@ static void ppc_core99_init(MachineState *machine)
>     fw_cfg = FW_CFG(dev);
>     qdev_prop_set_uint32(dev, "data_width", 1);
>     qdev_prop_set_bit(dev, "dma_enabled", false);
>-    object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
>-                              OBJECT(fw_cfg));
>+    object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
>     s = SYS_BUS_DEVICE(dev);
>     sysbus_realize_and_unref(s, &error_fatal);
>     sysbus_mmio_map(s, 0, CFG_ADDR);
>diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>index 558c639202..5a7b25a4a8 100644
>--- a/hw/ppc/mac_oldworld.c
>+++ b/hw/ppc/mac_oldworld.c
>@@ -303,8 +303,7 @@ static void ppc_heathrow_init(MachineState *machine)
>     fw_cfg = FW_CFG(dev);
>     qdev_prop_set_uint32(dev, "data_width", 1);
>     qdev_prop_set_bit(dev, "dma_enabled", false);
>-    object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
>-                              OBJECT(fw_cfg));
>+    object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
>     s = SYS_BUS_DEVICE(dev);
>     sysbus_realize_and_unref(s, &error_fatal);
>     sysbus_mmio_map(s, 0, CFG_ADDR);

Reviewed-by: Bernhard Beschow <shentey@gmail.com>

Re: [PATCH v7 2/7] mac_{old, new}world: Use local variable instead of qdev_get_machine()

[Mark Cave-Ayland]

On 04/01/2023 21:59, BALATON Zoltan wrote:

> We already have machine in a local variable so no need to use
> qdev_get_machine(), also remove now unneded line break.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>   hw/ppc/mac_newworld.c | 3 +--
>   hw/ppc/mac_oldworld.c | 3 +--
>   2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 601ea518f8..460c14b5e3 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -466,8 +466,7 @@ static void ppc_core99_init(MachineState *machine)
>       fw_cfg = FW_CFG(dev);
>       qdev_prop_set_uint32(dev, "data_width", 1);
>       qdev_prop_set_bit(dev, "dma_enabled", false);
> -    object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
> -                              OBJECT(fw_cfg));
> +    object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
>       s = SYS_BUS_DEVICE(dev);
>       sysbus_realize_and_unref(s, &error_fatal);
>       sysbus_mmio_map(s, 0, CFG_ADDR);
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 558c639202..5a7b25a4a8 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -303,8 +303,7 @@ static void ppc_heathrow_init(MachineState *machine)
>       fw_cfg = FW_CFG(dev);
>       qdev_prop_set_uint32(dev, "data_width", 1);
>       qdev_prop_set_bit(dev, "dma_enabled", false);
> -    object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
> -                              OBJECT(fw_cfg));
> +    object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
>       s = SYS_BUS_DEVICE(dev);
>       sysbus_realize_and_unref(s, &error_fatal);
>       sysbus_mmio_map(s, 0, CFG_ADDR);

Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>


ATB,

Mark.

[PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[BALATON Zoltan]

OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
ROM and add it to the device tree for MacOS. Pass the NDRV this way
instead of via fw_cfg. This solves the problem with OpenBIOS also
adding the NDRV to ati-vga which it does not work with. This does not
need any changes to OpenBIOS as this NDRV ROM handling is already
there but this patch also allows simplifying OpenBIOS later to remove
the fw_cfg ndrv handling from the vga FCode and also drop the
vga-ndrv? option which is not needed any more as users can disable the
ndrv with -device VGA,romfile="" (or override it with their own NDRV
or ROM). Once FCode support is implemented in OpenBIOS, the proper
FCode ROM can be set the same way so this paves the way to remove some
hacks.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
 hw/ppc/mac_newworld.c | 18 ++++++------------
 hw/ppc/mac_oldworld.c | 18 ++++++------------
 2 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 460c14b5e3..60c9c27986 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
     fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
     fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
 
-    /* MacOS NDRV VGA driver */
-    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
-    if (filename) {
-        gchar *ndrv_file;
-        gsize ndrv_size;
-
-        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
-            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
-        }
-        g_free(filename);
-    }
-
     qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
 }
 
@@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, const char *arg)
     return 2;
 }
 
+static GlobalProperty props[] = {
+    /* MacOS NDRV VGA driver */
+    { "VGA", "romfile", NDRV_VGA_FILENAME },
+};
+
 static void core99_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
@@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc, void *data)
 #endif
     mc->default_ram_id = "ppc_core99.ram";
     mc->ignore_boot_device_suffixes = true;
+    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
     fwc->get_dev_path = core99_fw_dev_path;
 }
 
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 5a7b25a4a8..6a1b1ad47a 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
     fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
     fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
 
-    /* MacOS NDRV VGA driver */
-    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
-    if (filename) {
-        gchar *ndrv_file;
-        gsize ndrv_size;
-
-        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
-            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
-        }
-        g_free(filename);
-    }
-
     qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
 }
 
@@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine, const char *arg)
     return 2;
 }
 
+static GlobalProperty props[] = {
+    /* MacOS NDRV VGA driver */
+    { "VGA", "romfile", NDRV_VGA_FILENAME },
+};
+
 static void heathrow_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
@@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)
     mc->default_display = "std";
     mc->ignore_boot_device_suffixes = true;
     mc->default_ram_id = "ppc_heathrow.ram";
+    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
     fwc->get_dev_path = heathrow_fw_dev_path;
 }
 
-- 
2.30.6

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[Mark Cave-Ayland]

On 04/01/2023 21:59, BALATON Zoltan wrote:

> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
> ROM and add it to the device tree for MacOS. Pass the NDRV this way
> instead of via fw_cfg. This solves the problem with OpenBIOS also
> adding the NDRV to ati-vga which it does not work with. This does not
> need any changes to OpenBIOS as this NDRV ROM handling is already
> there but this patch also allows simplifying OpenBIOS later to remove
> the fw_cfg ndrv handling from the vga FCode and also drop the
> vga-ndrv? option which is not needed any more as users can disable the
> ndrv with -device VGA,romfile="" (or override it with their own NDRV
> or ROM). Once FCode support is implemented in OpenBIOS, the proper
> FCode ROM can be set the same way so this paves the way to remove some
> hacks.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>   hw/ppc/mac_newworld.c | 18 ++++++------------
>   hw/ppc/mac_oldworld.c | 18 ++++++------------
>   2 files changed, 12 insertions(+), 24 deletions(-)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 460c14b5e3..60c9c27986 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>   
> -    /* MacOS NDRV VGA driver */
> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
> -    if (filename) {
> -        gchar *ndrv_file;
> -        gsize ndrv_size;
> -
> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
> -        }
> -        g_free(filename);
> -    }
> -
>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>   }
>   
> @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, const char *arg)
>       return 2;
>   }
>   
> +static GlobalProperty props[] = {
> +    /* MacOS NDRV VGA driver */
> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
> +};
> +
>   static void core99_machine_class_init(ObjectClass *oc, void *data)
>   {
>       MachineClass *mc = MACHINE_CLASS(oc);
> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc, void *data)
>   #endif
>       mc->default_ram_id = "ppc_core99.ram";
>       mc->ignore_boot_device_suffixes = true;
> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>       fwc->get_dev_path = core99_fw_dev_path;
>   }
>   
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 5a7b25a4a8..6a1b1ad47a 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>   
> -    /* MacOS NDRV VGA driver */
> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
> -    if (filename) {
> -        gchar *ndrv_file;
> -        gsize ndrv_size;
> -
> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
> -        }
> -        g_free(filename);
> -    }
> -
>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>   }
>   
> @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine, const char *arg)
>       return 2;
>   }
>   
> +static GlobalProperty props[] = {
> +    /* MacOS NDRV VGA driver */
> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
> +};
> +
>   static void heathrow_class_init(ObjectClass *oc, void *data)
>   {
>       MachineClass *mc = MACHINE_CLASS(oc);
> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)
>       mc->default_display = "std";
>       mc->ignore_boot_device_suffixes = true;
>       mc->default_ram_id = "ppc_heathrow.ram";
> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>       fwc->get_dev_path = heathrow_fw_dev_path;
>   }

The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM because it is 
a binary generated by a separate project: otherwise you'd end up creating a 
dependency between OpenBIOS and QemuMacDrivers, which is almost impossible to achieve 
since qemu_vga.ndrv can only (currently) be built in an emulated MacOS 9 guest.

The best way to do this would be to extract the PCI config words from your ATI 
OpenBIOS patches and the alter drivers/vga.fs so that it only generates the 
driver,AAPL,MacOS,PowerPC property if the device id and vendor id match that of the 
QEMU VGA device.


ATB,

Mark.

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[BALATON Zoltan]

On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
> On 04/01/2023 21:59, BALATON Zoltan wrote:
>> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
>> ROM and add it to the device tree for MacOS. Pass the NDRV this way
>> instead of via fw_cfg. This solves the problem with OpenBIOS also
>> adding the NDRV to ati-vga which it does not work with. This does not
>> need any changes to OpenBIOS as this NDRV ROM handling is already
>> there but this patch also allows simplifying OpenBIOS later to remove
>> the fw_cfg ndrv handling from the vga FCode and also drop the
>> vga-ndrv? option which is not needed any more as users can disable the
>> ndrv with -device VGA,romfile="" (or override it with their own NDRV
>> or ROM). Once FCode support is implemented in OpenBIOS, the proper
>> FCode ROM can be set the same way so this paves the way to remove some
>> hacks.
>> 
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>>   hw/ppc/mac_newworld.c | 18 ++++++------------
>>   hw/ppc/mac_oldworld.c | 18 ++++++------------
>>   2 files changed, 12 insertions(+), 24 deletions(-)
>> 
>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>> index 460c14b5e3..60c9c27986 100644
>> --- a/hw/ppc/mac_newworld.c
>> +++ b/hw/ppc/mac_newworld.c
>> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>>   -    /* MacOS NDRV VGA driver */
>> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>> -    if (filename) {
>> -        gchar *ndrv_file;
>> -        gsize ndrv_size;
>> -
>> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, 
>> ndrv_size);
>> -        }
>> -        g_free(filename);
>> -    }
>> -
>>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>   }
>>   @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, 
>> const char *arg)
>>       return 2;
>>   }
>>   +static GlobalProperty props[] = {
>> +    /* MacOS NDRV VGA driver */
>> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
>> +};
>> +
>>   static void core99_machine_class_init(ObjectClass *oc, void *data)
>>   {
>>       MachineClass *mc = MACHINE_CLASS(oc);
>> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc, 
>> void *data)
>>   #endif
>>       mc->default_ram_id = "ppc_core99.ram";
>>       mc->ignore_boot_device_suffixes = true;
>> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>       fwc->get_dev_path = core99_fw_dev_path;
>>   }
>>   diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>> index 5a7b25a4a8..6a1b1ad47a 100644
>> --- a/hw/ppc/mac_oldworld.c
>> +++ b/hw/ppc/mac_oldworld.c
>> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>   -    /* MacOS NDRV VGA driver */
>> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>> -    if (filename) {
>> -        gchar *ndrv_file;
>> -        gsize ndrv_size;
>> -
>> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, 
>> ndrv_size);
>> -        }
>> -        g_free(filename);
>> -    }
>> -
>>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>   }
>>   @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine, 
>> const char *arg)
>>       return 2;
>>   }
>>   +static GlobalProperty props[] = {
>> +    /* MacOS NDRV VGA driver */
>> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
>> +};
>> +
>>   static void heathrow_class_init(ObjectClass *oc, void *data)
>>   {
>>       MachineClass *mc = MACHINE_CLASS(oc);
>> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void 
>> *data)
>>       mc->default_display = "std";
>>       mc->ignore_boot_device_suffixes = true;
>>       mc->default_ram_id = "ppc_heathrow.ram";
>> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>       fwc->get_dev_path = heathrow_fw_dev_path;
>>   }
>
> The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM 
> because it is a binary generated by a separate project: otherwise you'd end 
> up creating a dependency between OpenBIOS and QemuMacDrivers, which is almost 
> impossible to achieve since qemu_vga.ndrv can only (currently) be built in an 
> emulated MacOS 9 guest.

I don't get this. The dependency is already there as qemu_vga.ndrv ships 
with QEMU such as all the vgabios-*.bin and SeaBIOS binaries which are 
also built from different projects. The qemu_vga.ndrv would also still be 
part of an FCode ROM together with vga.fs if OpenBIOS could run that so 
this patch solely changes the way of passing the ROM binary to OpenBIOS 
from fw_cfg to the card ROM which is closer to how it should be and can 
direcly be replaced with the FCode ROM later after OpenBIOS will be 
advanced to that point.

> The best way to do this would be to extract the PCI config words from your 
> ATI OpenBIOS patches and the alter drivers/vga.fs so that it only generates 
> the driver,AAPL,MacOS,PowerPC property if the device id and vendor id match 
> that of the QEMU VGA device.

This is further down the road and does not block this patch. The config 
access words should be provided by OpenBIOS not vga.fs. If we want to do 
it like on the real machine then vga.fs and qemu_vga,ndrv should be 
together the FCode ROM that the card has and OpenBIOS would run that. This 
is also how the ATI and NVIDIA ROMs do it which contain some Forth to init 
the card and add the embedded ndrv to the device tree for MacOS. But 
that's independent of this patch and needs OpenBIOS changes, while this 
patch does not need any change in OpenBIOS just moves to that direction to 
be able to attach a proper FCode ROM sometimes later and simpify fw_cfg 
handling in OpenBIOS. For now adding the ndrv in the ROM is enough for 
OpenBIOS as it has additional code to handle it already.

So this patch neither adds new dependency to QEMU nor repends on any 
change in OpenBIOS. It just gets rid of passing files via fw_cfg.

Regards,
BALATON Zoltan

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[Mark Cave-Ayland]

On 11/01/2023 00:54, BALATON Zoltan wrote:

> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
>>> ROM and add it to the device tree for MacOS. Pass the NDRV this way
>>> instead of via fw_cfg. This solves the problem with OpenBIOS also
>>> adding the NDRV to ati-vga which it does not work with. This does not
>>> need any changes to OpenBIOS as this NDRV ROM handling is already
>>> there but this patch also allows simplifying OpenBIOS later to remove
>>> the fw_cfg ndrv handling from the vga FCode and also drop the
>>> vga-ndrv? option which is not needed any more as users can disable the
>>> ndrv with -device VGA,romfile="" (or override it with their own NDRV
>>> or ROM). Once FCode support is implemented in OpenBIOS, the proper
>>> FCode ROM can be set the same way so this paves the way to remove some
>>> hacks.
>>>
>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>> ---
>>>   hw/ppc/mac_newworld.c | 18 ++++++------------
>>>   hw/ppc/mac_oldworld.c | 18 ++++++------------
>>>   2 files changed, 12 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>>> index 460c14b5e3..60c9c27986 100644
>>> --- a/hw/ppc/mac_newworld.c
>>> +++ b/hw/ppc/mac_newworld.c
>>> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>>>   -    /* MacOS NDRV VGA driver */
>>> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>> -    if (filename) {
>>> -        gchar *ndrv_file;
>>> -        gsize ndrv_size;
>>> -
>>> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>>> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
>>> -        }
>>> -        g_free(filename);
>>> -    }
>>> -
>>>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>>   }
>>>   @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, const 
>>> char *arg)
>>>       return 2;
>>>   }
>>>   +static GlobalProperty props[] = {
>>> +    /* MacOS NDRV VGA driver */
>>> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
>>> +};
>>> +
>>>   static void core99_machine_class_init(ObjectClass *oc, void *data)
>>>   {
>>>       MachineClass *mc = MACHINE_CLASS(oc);
>>> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc, void 
>>> *data)
>>>   #endif
>>>       mc->default_ram_id = "ppc_core99.ram";
>>>       mc->ignore_boot_device_suffixes = true;
>>> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>>       fwc->get_dev_path = core99_fw_dev_path;
>>>   }
>>>   diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>>> index 5a7b25a4a8..6a1b1ad47a 100644
>>> --- a/hw/ppc/mac_oldworld.c
>>> +++ b/hw/ppc/mac_oldworld.c
>>> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>>   -    /* MacOS NDRV VGA driver */
>>> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>> -    if (filename) {
>>> -        gchar *ndrv_file;
>>> -        gsize ndrv_size;
>>> -
>>> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>>> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
>>> -        }
>>> -        g_free(filename);
>>> -    }
>>> -
>>>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>>   }
>>>   @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine, const 
>>> char *arg)
>>>       return 2;
>>>   }
>>>   +static GlobalProperty props[] = {
>>> +    /* MacOS NDRV VGA driver */
>>> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
>>> +};
>>> +
>>>   static void heathrow_class_init(ObjectClass *oc, void *data)
>>>   {
>>>       MachineClass *mc = MACHINE_CLASS(oc);
>>> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)
>>>       mc->default_display = "std";
>>>       mc->ignore_boot_device_suffixes = true;
>>>       mc->default_ram_id = "ppc_heathrow.ram";
>>> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>>       fwc->get_dev_path = heathrow_fw_dev_path;
>>>   }
>>
>> The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM because it 
>> is a binary generated by a separate project: otherwise you'd end up creating a 
>> dependency between OpenBIOS and QemuMacDrivers, which is almost impossible to 
>> achieve since qemu_vga.ndrv can only (currently) be built in an emulated MacOS 9 
>> guest.
> 
> I don't get this. The dependency is already there as qemu_vga.ndrv ships with QEMU 
> such as all the vgabios-*.bin and SeaBIOS binaries which are also built from 
> different projects. The qemu_vga.ndrv would also still be part of an FCode ROM 
> together with vga.fs if OpenBIOS could run that so this patch solely changes the way 
> of passing the ROM binary to OpenBIOS from fw_cfg to the card ROM which is closer to 
> how it should be and can direcly be replaced with the FCode ROM later after OpenBIOS 
> will be advanced to that point.

Even if OpenBIOS were able to execute PCI option ROMs, the problem is that OpenBIOS 
cannot generate the qemu_vga.ndrv binary from source and therefore cannot generate 
the complete ROM by itself. Hence why the existing mechanism exists to inject 
qemu_vga.ndrv via fw_cfg() so the OpenBIOS ROM is self-contained.

>> The best way to do this would be to extract the PCI config words from your ATI 
>> OpenBIOS patches and the alter drivers/vga.fs so that it only generates the 
>> driver,AAPL,MacOS,PowerPC property if the device id and vendor id match that of the 
>> QEMU VGA device.
> 
> This is further down the road and does not block this patch. The config access words 
> should be provided by OpenBIOS not vga.fs. If we want to do it like on the real 
> machine then vga.fs and qemu_vga,ndrv should be together the FCode ROM that the card 
> has and OpenBIOS would run that. This is also how the ATI and NVIDIA ROMs do it which 
> contain some Forth to init the card and add the embedded ndrv to the device tree for 
> MacOS. But that's independent of this patch and needs OpenBIOS changes, while this 
> patch does not need any change in OpenBIOS just moves to that direction to be able to 
> attach a proper FCode ROM sometimes later and simpify fw_cfg handling in OpenBIOS. 
> For now adding the ndrv in the ROM is enough for OpenBIOS as it has additional code 
> to handle it already.

The problem you are ultimately trying to solve though is that OpenBIOS is loading the 
NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs so that the NDRV is 
loaded only for the QEMU VGA device?

> So this patch neither adds new dependency to QEMU nor repends on any change in 
> OpenBIOS. It just gets rid of passing files via fw_cfg.

Unfortunately that still doesn't solve the problem of building a self-contained 
OpenBIOS ROM, so this patch isn't the right way forward.


ATB,

Mark.

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 8829 bytes --]

On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
> On 11/01/2023 00:54, BALATON Zoltan wrote:
>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>>> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
>>>> ROM and add it to the device tree for MacOS. Pass the NDRV this way
>>>> instead of via fw_cfg. This solves the problem with OpenBIOS also
>>>> adding the NDRV to ati-vga which it does not work with. This does not
>>>> need any changes to OpenBIOS as this NDRV ROM handling is already
>>>> there but this patch also allows simplifying OpenBIOS later to remove
>>>> the fw_cfg ndrv handling from the vga FCode and also drop the
>>>> vga-ndrv? option which is not needed any more as users can disable the
>>>> ndrv with -device VGA,romfile="" (or override it with their own NDRV
>>>> or ROM). Once FCode support is implemented in OpenBIOS, the proper
>>>> FCode ROM can be set the same way so this paves the way to remove some
>>>> hacks.
>>>> 
>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>> ---
>>>>   hw/ppc/mac_newworld.c | 18 ++++++------------
>>>>   hw/ppc/mac_oldworld.c | 18 ++++++------------
>>>>   2 files changed, 12 insertions(+), 24 deletions(-)
>>>> 
>>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>>>> index 460c14b5e3..60c9c27986 100644
>>>> --- a/hw/ppc/mac_newworld.c
>>>> +++ b/hw/ppc/mac_newworld.c
>>>> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
>>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>>>>   -    /* MacOS NDRV VGA driver */
>>>> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>>> -    if (filename) {
>>>> -        gchar *ndrv_file;
>>>> -        gsize ndrv_size;
>>>> -
>>>> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) 
>>>> {
>>>> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, 
>>>> ndrv_size);
>>>> -        }
>>>> -        g_free(filename);
>>>> -    }
>>>> -
>>>>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>>>   }
>>>>   @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, 
>>>> const char *arg)
>>>>       return 2;
>>>>   }
>>>>   +static GlobalProperty props[] = {
>>>> +    /* MacOS NDRV VGA driver */
>>>> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
>>>> +};
>>>> +
>>>>   static void core99_machine_class_init(ObjectClass *oc, void *data)
>>>>   {
>>>>       MachineClass *mc = MACHINE_CLASS(oc);
>>>> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass 
>>>> *oc, void *data)
>>>>   #endif
>>>>       mc->default_ram_id = "ppc_core99.ram";
>>>>       mc->ignore_boot_device_suffixes = true;
>>>> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>>>       fwc->get_dev_path = core99_fw_dev_path;
>>>>   }
>>>>   diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>>>> index 5a7b25a4a8..6a1b1ad47a 100644
>>>> --- a/hw/ppc/mac_oldworld.c
>>>> +++ b/hw/ppc/mac_oldworld.c
>>>> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
>>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
>>>>       fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>>>   -    /* MacOS NDRV VGA driver */
>>>> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>>> -    if (filename) {
>>>> -        gchar *ndrv_file;
>>>> -        gsize ndrv_size;
>>>> -
>>>> -        if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) 
>>>> {
>>>> -            fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, 
>>>> ndrv_size);
>>>> -        }
>>>> -        g_free(filename);
>>>> -    }
>>>> -
>>>>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>>>   }
>>>>   @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState 
>>>> *machine, const char *arg)
>>>>       return 2;
>>>>   }
>>>>   +static GlobalProperty props[] = {
>>>> +    /* MacOS NDRV VGA driver */
>>>> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
>>>> +};
>>>> +
>>>>   static void heathrow_class_init(ObjectClass *oc, void *data)
>>>>   {
>>>>       MachineClass *mc = MACHINE_CLASS(oc);
>>>> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void 
>>>> *data)
>>>>       mc->default_display = "std";
>>>>       mc->ignore_boot_device_suffixes = true;
>>>>       mc->default_ram_id = "ppc_heathrow.ram";
>>>> +    compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>>>       fwc->get_dev_path = heathrow_fw_dev_path;
>>>>   }
>>> 
>>> The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM 
>>> because it is a binary generated by a separate project: otherwise you'd 
>>> end up creating a dependency between OpenBIOS and QemuMacDrivers, which is 
>>> almost impossible to achieve since qemu_vga.ndrv can only (currently) be 
>>> built in an emulated MacOS 9 guest.
>> 
>> I don't get this. The dependency is already there as qemu_vga.ndrv ships 
>> with QEMU such as all the vgabios-*.bin and SeaBIOS binaries which are also 
>> built from different projects. The qemu_vga.ndrv would also still be part 
>> of an FCode ROM together with vga.fs if OpenBIOS could run that so this 
>> patch solely changes the way of passing the ROM binary to OpenBIOS from 
>> fw_cfg to the card ROM which is closer to how it should be and can direcly 
>> be replaced with the FCode ROM later after OpenBIOS will be advanced to 
>> that point.
>
> Even if OpenBIOS were able to execute PCI option ROMs, the problem is that 
> OpenBIOS cannot generate the qemu_vga.ndrv binary from source and therefore 
> cannot generate the complete ROM by itself. Hence why the existing mechanism 
> exists to inject qemu_vga.ndrv via fw_cfg() so the OpenBIOS ROM is 
> self-contained.

And how does this change by this patch? The ndrv is built separately and 
included in QEMU currently. This does not change at all. The only thing 
that changes is that QEMU does not add it to fw_cfg but to the ROM where 
OpenBIOS adds it to the device tree but it can do it much simpler removing 
some code to handle downloading the file as it already reads the ROM. The 
option ROM is not self contained now and it will not be after this patch 
it's just a different way to solve the same issue simpler. What you don't 
like about it?

>>> The best way to do this would be to extract the PCI config words from your 
>>> ATI OpenBIOS patches and the alter drivers/vga.fs so that it only 
>>> generates the driver,AAPL,MacOS,PowerPC property if the device id and 
>>> vendor id match that of the QEMU VGA device.
>> 
>> This is further down the road and does not block this patch. The config 
>> access words should be provided by OpenBIOS not vga.fs. If we want to do it 
>> like on the real machine then vga.fs and qemu_vga,ndrv should be together 
>> the FCode ROM that the card has and OpenBIOS would run that. This is also 
>> how the ATI and NVIDIA ROMs do it which contain some Forth to init the card 
>> and add the embedded ndrv to the device tree for MacOS. But that's 
>> independent of this patch and needs OpenBIOS changes, while this patch does 
>> not need any change in OpenBIOS just moves to that direction to be able to 
>> attach a proper FCode ROM sometimes later and simpify fw_cfg handling in 
>> OpenBIOS. For now adding the ndrv in the ROM is enough for OpenBIOS as it 
>> has additional code to handle it already.
>
> The problem you are ultimately trying to solve though is that OpenBIOS is 
> loading the NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs 
> so that the NDRV is loaded only for the QEMU VGA device?
>
>> So this patch neither adds new dependency to QEMU nor repends on any change 
>> in OpenBIOS. It just gets rid of passing files via fw_cfg.
>
> Unfortunately that still doesn't solve the problem of building a 
> self-contained OpenBIOS ROM, so this patch isn't the right way forward.

It does take a step to make it possible to eventually add a self contained 
ROM and remove the vga.fs from OpenBIOS but it's not doing that fully. It 
just simplifies QEMU and OpenBIOS vga.fs for now and making the ROM also 
contain the FCode will be a further step but we can't get there if you 
don't allow to make smaller steps or don't merge my patches for OpenBIOS 
which would allow it to run FCode ROMs. If you're waiting for all this to 
be finished I'll give up and it will never be finished. If you allow to 
progress in smaller steps then maybe we'll get there.

Regards,
BALATON Zoltan

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[Mark Cave-Ayland]

On 22/01/2023 22:16, BALATON Zoltan wrote:

>> The problem you are ultimately trying to solve though is that OpenBIOS is loading 
>> the NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs so that the 
>> NDRV is loaded only for the QEMU VGA device?
>>
>>> So this patch neither adds new dependency to QEMU nor repends on any change in 
>>> OpenBIOS. It just gets rid of passing files via fw_cfg.
>>
>> Unfortunately that still doesn't solve the problem of building a self-contained 
>> OpenBIOS ROM, so this patch isn't the right way forward.
> 
> It does take a step to make it possible to eventually add a self contained ROM and 
> remove the vga.fs from OpenBIOS but it's not doing that fully. It just simplifies 
> QEMU and OpenBIOS vga.fs for now and making the ROM also contain the FCode will be a 
> further step but we can't get there if you don't allow to make smaller steps or don't 
> merge my patches for OpenBIOS which would allow it to run FCode ROMs. If you're 
> waiting for all this to be finished I'll give up and it will never be finished. If 
> you allow to progress in smaller steps then maybe we'll get there.

You can already add a self-contained rom using the romfile= property, so that's not 
preventing you from doing anything though? Even once OpenBIOS can read PCI option 
ROMs, the option ROM will still need to contain OpenBIOS's vga.fs as a payload, and 
it will still need to be able to inject qemu_vga.ndrv because OpenBIOS cannot have an 
external dependency upon QemuMacDrivers.


ATB,

Mark.

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[BALATON Zoltan]

On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
> On 22/01/2023 22:16, BALATON Zoltan wrote:
>>> The problem you are ultimately trying to solve though is that OpenBIOS is 
>>> loading the NDRV for all VGA PCI devices, so why not just fix 
>>> drivers/vga.fs so that the NDRV is loaded only for the QEMU VGA device?
>>> 
>>>> So this patch neither adds new dependency to QEMU nor repends on any 
>>>> change in OpenBIOS. It just gets rid of passing files via fw_cfg.
>>> 
>>> Unfortunately that still doesn't solve the problem of building a 
>>> self-contained OpenBIOS ROM, so this patch isn't the right way forward.
>> 
>> It does take a step to make it possible to eventually add a self contained 
>> ROM and remove the vga.fs from OpenBIOS but it's not doing that fully. It 
>> just simplifies QEMU and OpenBIOS vga.fs for now and making the ROM also 
>> contain the FCode will be a further step but we can't get there if you 
>> don't allow to make smaller steps or don't merge my patches for OpenBIOS 
>> which would allow it to run FCode ROMs. If you're waiting for all this to 
>> be finished I'll give up and it will never be finished. If you allow to 
>> progress in smaller steps then maybe we'll get there.
>
> You can already add a self-contained rom using the romfile= property, so 
> that's not preventing you from doing anything though? Even once OpenBIOS can

Except that OpenBIOS will break the device tree by adding the 
qemu_vga.ndrv to the video card node so the card rom I pass via romfile 
will see it's already there and won't install its owm. Then MacOS will try 
to use the wrong driver and it does not work and I spend a lot of time to 
find out I also need -prom env vga-ndrv?=false to avoid this problem which 
I always forget and somebody trying this for the first time won't even 
know.

What's more, all this complication is not needed. With this patch 
everything works as before for std VGA as it will have the qemu_vga.ndrv 
as its romfile but ati-vga won't so OpenBIOS only installs it for std VGA 
without adding anything to OpenBIOS to handle this. Adding a romfile to 
ati-vga will work without further hassle and the romfile option can also 
be used to replace or disable the qemu_vga.ndrv for std VGA as -device 
VGA,romdile="" (or add your FCode in development here). Due to the way 
standard VGA works adding -device VGA,romfile= to the command line won't 
add a second VGA device just set the option for the default one (actually 
it omits the default and adds the specified one but the point is this 
just works).

Then we not only not need to add anythig to OpenBIOS but we can drop the 
vga-ndrv? option (which does not exist on real machines anyway) and also 
all the code in vga.fs to get the driver from fw_cfg so simplifying it 
leaving only the code which will eventually need to be part of the FCode 
ROM. Once this patch is accepted it fixes the above problem and allows to 
simplify OpenBIOS later and when we're there you just have to replace 
qemu_vga.ndrv with the version that prepends the FCode from vga.fs before 
it so I don't see what's your problem with this patch. Can you give a 
reason why it can't be accepted?

> read PCI option ROMs, the option ROM will still need to contain OpenBIOS's 
> vga.fs as a payload, and it will still need to be able to inject 
> qemu_vga.ndrv because OpenBIOS cannot have an external dependency upon 
> QemuMacDrivers.

The way real card ROMs work is that they embed the driver binary and have 
some FCode that adds that to the device tree. It should be the same for 
QEMU emulated cards so if you say that you want only vga.fs as the card 
ROM which then downloads the qemu_vga.ndrv from QEMU that makes no sense 
at all. Currently the qemu_vga.ndrv is build from QemuMacDrivers and added 
as a binary to QEMU. You can add it as a binary the same way to OpenBIOS 
then build the FCOde ROM from vga.fs and qemu_vga.ndrv bin that results in 
the FCode ROM that will replace qemu_vga.ndrv binaty in QEMU. You just say 
this is not possible because you're OK with adding the qemu_vga,ndrv 
binary to QEMU but doing the same with OpenBIOS cannot be done?

Regards,
BALATON Zoltan

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[Mark Cave-Ayland]

On 24/01/2023 00:13, BALATON Zoltan wrote:

> On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
>> On 22/01/2023 22:16, BALATON Zoltan wrote:
>>>> The problem you are ultimately trying to solve though is that OpenBIOS is loading 
>>>> the NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs so that the 
>>>> NDRV is loaded only for the QEMU VGA device?
>>>>
>>>>> So this patch neither adds new dependency to QEMU nor repends on any change in 
>>>>> OpenBIOS. It just gets rid of passing files via fw_cfg.
>>>>
>>>> Unfortunately that still doesn't solve the problem of building a self-contained 
>>>> OpenBIOS ROM, so this patch isn't the right way forward.
>>>
>>> It does take a step to make it possible to eventually add a self contained ROM and 
>>> remove the vga.fs from OpenBIOS but it's not doing that fully. It just simplifies 
>>> QEMU and OpenBIOS vga.fs for now and making the ROM also contain the FCode will be 
>>> a further step but we can't get there if you don't allow to make smaller steps or 
>>> don't merge my patches for OpenBIOS which would allow it to run FCode ROMs. If 
>>> you're waiting for all this to be finished I'll give up and it will never be 
>>> finished. If you allow to progress in smaller steps then maybe we'll get there.
>>
>> You can already add a self-contained rom using the romfile= property, so that's not 
>> preventing you from doing anything though? Even once OpenBIOS can
> 
> Except that OpenBIOS will break the device tree by adding the qemu_vga.ndrv to the 
> video card node so the card rom I pass via romfile will see it's already there and 
> won't install its owm. Then MacOS will try to use the wrong driver and it does not 
> work and I spend a lot of time to find out I also need -prom env vga-ndrv?=false to 
> avoid this problem which I always forget and somebody trying this for the first time 
> won't even know.
> 
> What's more, all this complication is not needed. With this patch everything works as 
> before for std VGA as it will have the qemu_vga.ndrv as its romfile but ati-vga won't 
> so OpenBIOS only installs it for std VGA without adding anything to OpenBIOS to 
> handle this. Adding a romfile to ati-vga will work without further hassle and the 
> romfile option can also be used to replace or disable the qemu_vga.ndrv for std VGA 
> as -device VGA,romdile="" (or add your FCode in development here). Due to the way 
> standard VGA works adding -device VGA,romfile= to the command line won't add a second 
> VGA device just set the option for the default one (actually it omits the default and 
> adds the specified one but the point is this just works).
> 
> Then we not only not need to add anythig to OpenBIOS but we can drop the vga-ndrv? 
> option (which does not exist on real machines anyway) and also all the code in vga.fs 
> to get the driver from fw_cfg so simplifying it leaving only the code which will 
> eventually need to be part of the FCode ROM. Once this patch is accepted it fixes the 
> above problem and allows to simplify OpenBIOS later and when we're there you just 
> have to replace qemu_vga.ndrv with the version that prepends the FCode from vga.fs 
> before it so I don't see what's your problem with this patch. Can you give a reason 
> why it can't be accepted?

It doesn't work this way though: once the FCode ROM is working it also generates the 
QEMU,VGA device tree node, which means that -device VGA,romfile="" will not only 
disable qemu_vga.ndrv, but also leave a device node missing the properties required 
for the guest to correctly identify the VGA adapter.

As I already mentioned, this is the wrong approach and what is needed is to fix 
vga.fs in OpenBIOS so that the NDRV is only loaded for the QEMU,VGA device.

>> read PCI option ROMs, the option ROM will still need to contain OpenBIOS's vga.fs 
>> as a payload, and it will still need to be able to inject qemu_vga.ndrv because 
>> OpenBIOS cannot have an external dependency upon QemuMacDrivers.
> 
> The way real card ROMs work is that they embed the driver binary and have some FCode 
> that adds that to the device tree. It should be the same for QEMU emulated cards so 
> if you say that you want only vga.fs as the card ROM which then downloads the 
> qemu_vga.ndrv from QEMU that makes no sense at all. Currently the qemu_vga.ndrv is 
> build from QemuMacDrivers and added as a binary to QEMU. You can add it as a binary 
> the same way to OpenBIOS then build the FCOde ROM from vga.fs and qemu_vga.ndrv bin 
> that results in the FCode ROM that will replace qemu_vga.ndrv binaty in QEMU. You 
> just say this is not possible because you're OK with adding the qemu_vga,ndrv binary 
> to QEMU but doing the same with OpenBIOS cannot be done?

What you're suggesting doesn't make any sense, as all you're doing is moving the 
binary from QEMU where there is already precedent for distributing binary ROMs to 
OpenBIOS where it becomes a build dependency that cannot be built outside of a very 
specific guest environment.

I should also add that it wasn't me who designed and implemented the existing scheme 
for keeping the qemu_vga.ndrv binary in QEMU, it was Ben - and his approach still 
seems to be the best solution in my opinion.


ATB,

Mark.

Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg

[BALATON Zoltan]

On Wed, 1 Feb 2023, Mark Cave-Ayland wrote:
> On 24/01/2023 00:13, BALATON Zoltan wrote:
>> On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
>>> On 22/01/2023 22:16, BALATON Zoltan wrote:
>>>>> The problem you are ultimately trying to solve though is that OpenBIOS 
>>>>> is loading the NDRV for all VGA PCI devices, so why not just fix 
>>>>> drivers/vga.fs so that the NDRV is loaded only for the QEMU VGA device?
>>>>> 
>>>>>> So this patch neither adds new dependency to QEMU nor repends on any 
>>>>>> change in OpenBIOS. It just gets rid of passing files via fw_cfg.
>>>>> 
>>>>> Unfortunately that still doesn't solve the problem of building a 
>>>>> self-contained OpenBIOS ROM, so this patch isn't the right way forward.
>>>> 
>>>> It does take a step to make it possible to eventually add a self 
>>>> contained ROM and remove the vga.fs from OpenBIOS but it's not doing that 
>>>> fully. It just simplifies QEMU and OpenBIOS vga.fs for now and making the 
>>>> ROM also contain the FCode will be a further step but we can't get there 
>>>> if you don't allow to make smaller steps or don't merge my patches for 
>>>> OpenBIOS which would allow it to run FCode ROMs. If you're waiting for 
>>>> all this to be finished I'll give up and it will never be finished. If 
>>>> you allow to progress in smaller steps then maybe we'll get there.
>>> 
>>> You can already add a self-contained rom using the romfile= property, so 
>>> that's not preventing you from doing anything though? Even once OpenBIOS 
>>> can
>> 
>> Except that OpenBIOS will break the device tree by adding the qemu_vga.ndrv 
>> to the video card node so the card rom I pass via romfile will see it's 
>> already there and won't install its owm. Then MacOS will try to use the 
>> wrong driver and it does not work and I spend a lot of time to find out I 
>> also need -prom env vga-ndrv?=false to avoid this problem which I always 
>> forget and somebody trying this for the first time won't even know.
>> 
>> What's more, all this complication is not needed. With this patch 
>> everything works as before for std VGA as it will have the qemu_vga.ndrv as 
>> its romfile but ati-vga won't so OpenBIOS only installs it for std VGA 
>> without adding anything to OpenBIOS to handle this. Adding a romfile to 
>> ati-vga will work without further hassle and the romfile option can also be 
>> used to replace or disable the qemu_vga.ndrv for std VGA as -device 
>> VGA,romdile="" (or add your FCode in development here). Due to the way 
>> standard VGA works adding -device VGA,romfile= to the command line won't 
>> add a second VGA device just set the option for the default one (actually 
>> it omits the default and adds the specified one but the point is this just 
>> works).
>> 
>> Then we not only not need to add anythig to OpenBIOS but we can drop the 
>> vga-ndrv? option (which does not exist on real machines anyway) and also 
>> all the code in vga.fs to get the driver from fw_cfg so simplifying it 
>> leaving only the code which will eventually need to be part of the FCode 
>> ROM. Once this patch is accepted it fixes the above problem and allows to 
>> simplify OpenBIOS later and when we're there you just have to replace 
>> qemu_vga.ndrv with the version that prepends the FCode from vga.fs before 
>> it so I don't see what's your problem with this patch. Can you give a 
>> reason why it can't be accepted?
>
> It doesn't work this way though: once the FCode ROM is working it also 
> generates the QEMU,VGA device tree node, which means that -device 
> VGA,romfile="" will not only disable qemu_vga.ndrv, but also leave a device 
> node missing the properties required for the guest to correctly identify the 
> VGA adapter.

Under what circumstances does it make sense to not have the ndrv in the 
device tree when using vga.fs or a ROM built from that later?

> As I already mentioned, this is the wrong approach and what is needed is to 
> fix vga.fs in OpenBIOS so that the NDRV is only loaded for the QEMU,VGA 
> device.

Then please do that as it's your code and I don't want to find out how to 
change the forth in vga.fs to do this.

>>> read PCI option ROMs, the option ROM will still need to contain OpenBIOS's 
>>> vga.fs as a payload, and it will still need to be able to inject 
>>> qemu_vga.ndrv because OpenBIOS cannot have an external dependency upon 
>>> QemuMacDrivers.
>> 
>> The way real card ROMs work is that they embed the driver binary and have 
>> some FCode that adds that to the device tree. It should be the same for 
>> QEMU emulated cards so if you say that you want only vga.fs as the card ROM 
>> which then downloads the qemu_vga.ndrv from QEMU that makes no sense at 
>> all. Currently the qemu_vga.ndrv is build from QemuMacDrivers and added as 
>> a binary to QEMU. You can add it as a binary the same way to OpenBIOS then 
>> build the FCOde ROM from vga.fs and qemu_vga.ndrv bin that results in the 
>> FCode ROM that will replace qemu_vga.ndrv binaty in QEMU. You just say this 
>> is not possible because you're OK with adding the qemu_vga,ndrv binary to 
>> QEMU but doing the same with OpenBIOS cannot be done?
>
> What you're suggesting doesn't make any sense, as all you're doing is moving 
> the binary from QEMU where there is already precedent for distributing binary 
> ROMs to OpenBIOS where it becomes a build dependency that cannot be built 
> outside of a very specific guest environment.
>
> I should also add that it wasn't me who designed and implemented the existing 
> scheme for keeping the qemu_vga.ndrv binary in QEMU, it was Ben - and his 
> approach still seems to be the best solution in my opinion.

Since I can't convince you I'll leave this for now but it would help if 
you could come up with an alternative patch at least solving the problem 
of adding the ndrv to vga devices it does not work with. I like the 
romfile="" option also because this is needed for other firmwares with 
ati-vga that have BIOS emulator that can't run the default vgabios from 
QEMU because it contains i386 opcodes that those firmwares' x86 emulators 
don't know about. So I'm already listing that option for ati-vga for 
sam460ex and pegasos2 in user docs and if the same worked for 
mac99,via=pmu that would be simpler for users (and for me always 
forgetting about the option to prevent ndrv loading as I don't use it very 
often).

Regards,
BALATON Zoltan

[PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[BALATON Zoltan]

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.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
 hw/ppc/mac_newworld.c | 94 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 60c9c27986..3f5d1ec097 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -642,9 +642,103 @@ static const TypeInfo core99_machine_info = {
     },
 };
 
+static void powermac3_1_machine_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    core99_machine_class_init(oc, data);
+    mc->desc = "Apple Power Mac G4 AGP (Sawtooth)";
+    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
+}
+
+static void powermac3_1_instance_init(Object *obj)
+{
+    Core99MachineState *cms = CORE99_MACHINE(obj);
+
+    cms->via_config = CORE99_VIA_CONFIG_PMU;
+    return;
+}
+
+static const TypeInfo powermac3_1_machine_info = {
+    .name          = MACHINE_TYPE_NAME("powermac3_1"),
+    .parent        = TYPE_MACHINE,
+    .class_init    = powermac3_1_machine_class_init,
+    .instance_init = powermac3_1_instance_init,
+    .instance_size = sizeof(Core99MachineState),
+    .interfaces = (InterfaceInfo[]) {
+        { TYPE_FW_PATH_PROVIDER },
+        { }
+    },
+};
+
+static void powerbook3_2_machine_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    core99_machine_class_init(oc, data);
+    mc->desc = "Apple PowerBook G4 Titanium (Mercury)";
+    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
+}
+
+static void powerbook3_2_instance_init(Object *obj)
+{
+    Core99MachineState *cms = CORE99_MACHINE(obj);
+
+    cms->via_config = CORE99_VIA_CONFIG_PMU_ADB;
+    return;
+}
+
+static const TypeInfo powerbook3_2_machine_info = {
+    .name          = MACHINE_TYPE_NAME("powerbook3_2"),
+    .parent        = TYPE_MACHINE,
+    .class_init    = powerbook3_2_machine_class_init,
+    .instance_init = powerbook3_2_instance_init,
+    .instance_size = sizeof(Core99MachineState),
+    .interfaces = (InterfaceInfo[]) {
+        { TYPE_FW_PATH_PROVIDER },
+        { }
+    },
+};
+
+#ifdef TARGET_PPC64
+static void powermac7_3_machine_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    core99_machine_class_init(oc, data);
+    mc->desc = "Apple Power Mac G5 (Niagara)";
+    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("970fx_v3.1");
+}
+
+static void powermac7_3_instance_init(Object *obj)
+{
+    Core99MachineState *cms = CORE99_MACHINE(obj);
+
+    cms->via_config = CORE99_VIA_CONFIG_PMU;
+    return;
+}
+
+static const TypeInfo powermac7_3_machine_info = {
+    .name          = MACHINE_TYPE_NAME("powermac7_3"),
+    .parent        = TYPE_MACHINE,
+    .class_init    = powermac7_3_machine_class_init,
+    .instance_init = powermac7_3_instance_init,
+    .instance_size = sizeof(Core99MachineState),
+    .interfaces = (InterfaceInfo[]) {
+        { TYPE_FW_PATH_PROVIDER },
+        { }
+    },
+};
+#endif
+
 static void mac_machine_register_types(void)
 {
     type_register_static(&core99_machine_info);
+    type_register_static(&powermac3_1_machine_info);
+    type_register_static(&powerbook3_2_machine_info);
+#ifdef TARGET_PPC64
+    type_register_static(&powermac7_3_machine_info);
+#endif
 }
 
 type_init(mac_machine_register_types)
-- 
2.30.6

Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[Mark Cave-Ayland]

On 04/01/2023 21:59, 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.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>

Some thoughts on this: the first is that not everyone agrees that for qemu-system-X 
that X represents the target. There were previous discussion where some KVM people 
assumed X represented the host, i.e. ppc64 was the binary that ran all PPC guests but 
with hardware acceleration for ppc64 guests on ppc64 hosts. This was a while ago, so 
it may be worth starting a thread on qemu-devel to see what the current consensus is.

Secondly it's not clear to me why you've chosen names like "powermac_3_1" instead of 
"g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth model? For QEMU it 
is always best to emulate real machines, and whilst I understand you want to separate 
out the two versions of the mac99 machine, having "powermac_X_Y" seems less clear to me.

Finally can you post links to the device trees that you are using for each of the new 
machine types so that we have a clear reference point for future changes to the QEMU 
Mac machines? Even better include the links in the comments for each machine so that 
the information is easily visible for developers.

> ---
>   hw/ppc/mac_newworld.c | 94 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 94 insertions(+)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 60c9c27986..3f5d1ec097 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -642,9 +642,103 @@ static const TypeInfo core99_machine_info = {
>       },
>   };
>   
> +static void powermac3_1_machine_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +
> +    core99_machine_class_init(oc, data);
> +    mc->desc = "Apple Power Mac G4 AGP (Sawtooth)";
> +    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
> +}
> +
> +static void powermac3_1_instance_init(Object *obj)
> +{
> +    Core99MachineState *cms = CORE99_MACHINE(obj);
> +
> +    cms->via_config = CORE99_VIA_CONFIG_PMU;
> +    return;
> +}
> +
> +static const TypeInfo powermac3_1_machine_info = {
> +    .name          = MACHINE_TYPE_NAME("powermac3_1"),
> +    .parent        = TYPE_MACHINE,
> +    .class_init    = powermac3_1_machine_class_init,
> +    .instance_init = powermac3_1_instance_init,
> +    .instance_size = sizeof(Core99MachineState),
> +    .interfaces = (InterfaceInfo[]) {
> +        { TYPE_FW_PATH_PROVIDER },
> +        { }
> +    },
> +};
> +
> +static void powerbook3_2_machine_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +
> +    core99_machine_class_init(oc, data);
> +    mc->desc = "Apple PowerBook G4 Titanium (Mercury)";
> +    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
> +}
> +
> +static void powerbook3_2_instance_init(Object *obj)
> +{
> +    Core99MachineState *cms = CORE99_MACHINE(obj);
> +
> +    cms->via_config = CORE99_VIA_CONFIG_PMU_ADB;
> +    return;
> +}
> +
> +static const TypeInfo powerbook3_2_machine_info = {
> +    .name          = MACHINE_TYPE_NAME("powerbook3_2"),
> +    .parent        = TYPE_MACHINE,
> +    .class_init    = powerbook3_2_machine_class_init,
> +    .instance_init = powerbook3_2_instance_init,
> +    .instance_size = sizeof(Core99MachineState),
> +    .interfaces = (InterfaceInfo[]) {
> +        { TYPE_FW_PATH_PROVIDER },
> +        { }
> +    },
> +};
> +
> +#ifdef TARGET_PPC64
> +static void powermac7_3_machine_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +
> +    core99_machine_class_init(oc, data);
> +    mc->desc = "Apple Power Mac G5 (Niagara)";
> +    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("970fx_v3.1");
> +}
> +
> +static void powermac7_3_instance_init(Object *obj)
> +{
> +    Core99MachineState *cms = CORE99_MACHINE(obj);
> +
> +    cms->via_config = CORE99_VIA_CONFIG_PMU;
> +    return;
> +}
> +
> +static const TypeInfo powermac7_3_machine_info = {
> +    .name          = MACHINE_TYPE_NAME("powermac7_3"),
> +    .parent        = TYPE_MACHINE,
> +    .class_init    = powermac7_3_machine_class_init,
> +    .instance_init = powermac7_3_instance_init,
> +    .instance_size = sizeof(Core99MachineState),
> +    .interfaces = (InterfaceInfo[]) {
> +        { TYPE_FW_PATH_PROVIDER },
> +        { }
> +    },
> +};
> +#endif
> +
>   static void mac_machine_register_types(void)
>   {
>       type_register_static(&core99_machine_info);
> +    type_register_static(&powermac3_1_machine_info);
> +    type_register_static(&powerbook3_2_machine_info);
> +#ifdef TARGET_PPC64
> +    type_register_static(&powermac7_3_machine_info);
> +#endif
>   }
>   
>   type_init(mac_machine_register_types)


ATB,

Mark.

Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[BALATON Zoltan]

On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
> On 04/01/2023 21:59, 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.
>> 
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>
> Some thoughts on this: the first is that not everyone agrees that for 
> qemu-system-X that X represents the target. There were previous discussion 
> where some KVM people assumed X represented the host, i.e. ppc64 was the 
> binary that ran all PPC guests but with hardware acceleration for ppc64 
> guests on ppc64 hosts. This was a while ago, so it may be worth starting a 
> thread on qemu-devel to see what the current consensus is.

I don't see how this is relevant to this series, Also likely not the case 
any more as qemu-system-ppc and qemu-system-ppc64 share most of the code 
since a while with ppc64 including the config of ppc and adding more 
machines.

> Secondly it's not clear to me why you've chosen names like "powermac_3_1" 
> instead of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth 
> model? For QEMU it is always best to emulate real machines, and whilst I 
> understand you want to separate out the two versions of the mac99 machine, 
> having "powermac_X_Y" seems less clear to me.

These machine model identifiers are used by Apple to uniquely identify 
(all of) their machines since new-world Macs (even modern iPads and Macs 
have them) so for Mac people this should be clearer than the informal 
names that could get a bit long and confusing as there may be slight 
differences within a family. In any case, qemu-system-ppc -M mac99 is not 
corresponding to any real Mac so I'd like the options which do emulate 
real Macs to be called in a name that show which Mac is that. For the PPC 
Macs there's some info here for example:

https://en.wikipedia.org/wiki/Power_Mac_G4

And everymac.com also has info on all Macs. There were actually more than 
one G4 PowerMac with AGP but the other one was informally called gigabit 
ethernet. So the model ID is a shorter and better way to clearly identify 
which hardware is it (and it's also referenced in the device-tree of these 
Macs).

> Finally can you post links to the device trees that you are using for each of 
> the new machine types so that we have a clear reference point for future 
> changes to the QEMU Mac machines? Even better include the links in the 
> comments for each machine so that the information is easily visible for 
> developers.

I still have those I've posted over the past 8 years when I made changes 
to OpenBIOS to make the device-tree closer to real machine. I've 
downloaded it back then, don't know where to find it now but searching for 
e.g. "PowerMac3,1" "device-tree" should get some results.

Regards,
BALATON Zoltan

>> ---
>>   hw/ppc/mac_newworld.c | 94 +++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 94 insertions(+)
>> 
>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>> index 60c9c27986..3f5d1ec097 100644
>> --- a/hw/ppc/mac_newworld.c
>> +++ b/hw/ppc/mac_newworld.c
>> @@ -642,9 +642,103 @@ static const TypeInfo core99_machine_info = {
>>       },
>>   };
>>   +static void powermac3_1_machine_class_init(ObjectClass *oc, void *data)
>> +{
>> +    MachineClass *mc = MACHINE_CLASS(oc);
>> +
>> +    core99_machine_class_init(oc, data);
>> +    mc->desc = "Apple Power Mac G4 AGP (Sawtooth)";
>> +    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
>> +}
>> +
>> +static void powermac3_1_instance_init(Object *obj)
>> +{
>> +    Core99MachineState *cms = CORE99_MACHINE(obj);
>> +
>> +    cms->via_config = CORE99_VIA_CONFIG_PMU;
>> +    return;
>> +}
>> +
>> +static const TypeInfo powermac3_1_machine_info = {
>> +    .name          = MACHINE_TYPE_NAME("powermac3_1"),
>> +    .parent        = TYPE_MACHINE,
>> +    .class_init    = powermac3_1_machine_class_init,
>> +    .instance_init = powermac3_1_instance_init,
>> +    .instance_size = sizeof(Core99MachineState),
>> +    .interfaces = (InterfaceInfo[]) {
>> +        { TYPE_FW_PATH_PROVIDER },
>> +        { }
>> +    },
>> +};
>> +
>> +static void powerbook3_2_machine_class_init(ObjectClass *oc, void *data)
>> +{
>> +    MachineClass *mc = MACHINE_CLASS(oc);
>> +
>> +    core99_machine_class_init(oc, data);
>> +    mc->desc = "Apple PowerBook G4 Titanium (Mercury)";
>> +    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
>> +}
>> +
>> +static void powerbook3_2_instance_init(Object *obj)
>> +{
>> +    Core99MachineState *cms = CORE99_MACHINE(obj);
>> +
>> +    cms->via_config = CORE99_VIA_CONFIG_PMU_ADB;
>> +    return;
>> +}
>> +
>> +static const TypeInfo powerbook3_2_machine_info = {
>> +    .name          = MACHINE_TYPE_NAME("powerbook3_2"),
>> +    .parent        = TYPE_MACHINE,
>> +    .class_init    = powerbook3_2_machine_class_init,
>> +    .instance_init = powerbook3_2_instance_init,
>> +    .instance_size = sizeof(Core99MachineState),
>> +    .interfaces = (InterfaceInfo[]) {
>> +        { TYPE_FW_PATH_PROVIDER },
>> +        { }
>> +    },
>> +};
>> +
>> +#ifdef TARGET_PPC64
>> +static void powermac7_3_machine_class_init(ObjectClass *oc, void *data)
>> +{
>> +    MachineClass *mc = MACHINE_CLASS(oc);
>> +
>> +    core99_machine_class_init(oc, data);
>> +    mc->desc = "Apple Power Mac G5 (Niagara)";
>> +    mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("970fx_v3.1");
>> +}
>> +
>> +static void powermac7_3_instance_init(Object *obj)
>> +{
>> +    Core99MachineState *cms = CORE99_MACHINE(obj);
>> +
>> +    cms->via_config = CORE99_VIA_CONFIG_PMU;
>> +    return;
>> +}
>> +
>> +static const TypeInfo powermac7_3_machine_info = {
>> +    .name          = MACHINE_TYPE_NAME("powermac7_3"),
>> +    .parent        = TYPE_MACHINE,
>> +    .class_init    = powermac7_3_machine_class_init,
>> +    .instance_init = powermac7_3_instance_init,
>> +    .instance_size = sizeof(Core99MachineState),
>> +    .interfaces = (InterfaceInfo[]) {
>> +        { TYPE_FW_PATH_PROVIDER },
>> +        { }
>> +    },
>> +};
>> +#endif
>> +
>>   static void mac_machine_register_types(void)
>>   {
>>       type_register_static(&core99_machine_info);
>> +    type_register_static(&powermac3_1_machine_info);
>> +    type_register_static(&powerbook3_2_machine_info);
>> +#ifdef TARGET_PPC64
>> +    type_register_static(&powermac7_3_machine_info);
>> +#endif
>>   }
>>     type_init(mac_machine_register_types)
>
>
> ATB,
>
> Mark.
>
>

Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[Mark Cave-Ayland]

On 11/01/2023 00:36, BALATON Zoltan wrote:

> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>> On 04/01/2023 21:59, 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.
>>>
>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>
>> Some thoughts on this: the first is that not everyone agrees that for qemu-system-X 
>> that X represents the target. There were previous discussion where some KVM people 
>> assumed X represented the host, i.e. ppc64 was the binary that ran all PPC guests 
>> but with hardware acceleration for ppc64 guests on ppc64 hosts. This was a while 
>> ago, so it may be worth starting a thread on qemu-devel to see what the current 
>> consensus is.
> 
> I don't see how this is relevant to this series, Also likely not the case any more as 
> qemu-system-ppc and qemu-system-ppc64 share most of the code since a while with ppc64 
> including the config of ppc and adding more machines.

Well the patch defines the powermac 7.3 machine just for TARGET_PPC64, no? So you're 
making the assumption qemu-system-ppc64 represents a 64-bit target rather than a 
64-bit host.

>> Secondly it's not clear to me why you've chosen names like "powermac_3_1" instead 
>> of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth model? For QEMU 
>> it is always best to emulate real machines, and whilst I understand you want to 
>> separate out the two versions of the mac99 machine, having "powermac_X_Y" seems 
>> less clear to me.
> 
> These machine model identifiers are used by Apple to uniquely identify (all of) their 
> machines since new-world Macs (even modern iPads and Macs have them) so for Mac 
> people this should be clearer than the informal names that could get a bit long and 
> confusing as there may be slight differences within a family. In any case, 
> qemu-system-ppc -M mac99 is not corresponding to any real Mac so I'd like the options 
> which do emulate real Macs to be called in a name that show which Mac is that. For 
> the PPC Macs there's some info here for example:
> 
> https://en.wikipedia.org/wiki/Power_Mac_G4
> 
> And everymac.com also has info on all Macs. There were actually more than one G4 
> PowerMac with AGP but the other one was informally called gigabit ethernet. So the 
> model ID is a shorter and better way to clearly identify which hardware is it (and 
> it's also referenced in the device-tree of these Macs).

Are you planning to work on different types of G4 Mac where this could be confusing? 
Even to me "PowerMac 3.1" doesn't really tell me what model of Mac is being emulated, 
whereas "g4agp" (much in the same way as g3beige) is much more friendlier to people 
interested in using QEMU for Mac emulation.

>> Finally can you post links to the device trees that you are using for each of the 
>> new machine types so that we have a clear reference point for future changes to the 
>> QEMU Mac machines? Even better include the links in the comments for each machine 
>> so that the information is easily visible for developers.
> 
> I still have those I've posted over the past 8 years when I made changes to OpenBIOS 
> to make the device-tree closer to real machine. I've downloaded it back then, don't 
> know where to find it now but searching for e.g. "PowerMac3,1" "device-tree" should 
> get some results.

Nothing shows up for me, I'm afraid (remember that Google searches are unique to each 
user). If you want argue for changing the QEMU machines, then we should agree on the 
reference device model for future changes.


ATB,

Mark.

Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[BALATON Zoltan]

On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
> On 11/01/2023 00:36, BALATON Zoltan wrote:
>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>> On 04/01/2023 21:59, 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.
>>>> 
>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>> 
>>> Some thoughts on this: the first is that not everyone agrees that for 
>>> qemu-system-X that X represents the target. There were previous discussion 
>>> where some KVM people assumed X represented the host, i.e. ppc64 was the 
>>> binary that ran all PPC guests but with hardware acceleration for ppc64 
>>> guests on ppc64 hosts. This was a while ago, so it may be worth starting a 
>>> thread on qemu-devel to see what the current consensus is.
>> 
>> I don't see how this is relevant to this series, Also likely not the case 
>> any more as qemu-system-ppc and qemu-system-ppc64 share most of the code 
>> since a while with ppc64 including the config of ppc and adding more 
>> machines.
>
> Well the patch defines the powermac 7.3 machine just for TARGET_PPC64, no? So 
> you're making the assumption qemu-system-ppc64 represents a 64-bit target 
> rather than a 64-bit host.

I'm not making that assumption, it's already there:

$ qemu-system-ppc -machine help
Supported machines are:
40p                  IBM RS/6000 7020 (40p)
bamboo               bamboo
g3beige              Heathrow based PowerMAC (default)
mac99                Mac99 based PowerMAC
mpc8544ds            mpc8544ds
none                 empty machine
pegasos2             Genesi/bPlan Pegasos II
ppce500              generic paravirt e500 platform
ref405ep             ref405ep
sam460ex             aCube Sam460ex
virtex-ml507         Xilinx Virtex ML507 reference design

$ qemu-system-ppc64 -machine help
Supported machines are:
40p                  IBM RS/6000 7020 (40p)
bamboo               bamboo
g3beige              Heathrow based PowerMAC
mac99                Mac99 based PowerMAC
mpc8544ds            mpc8544ds
none                 empty machine
pegasos2             Genesi/bPlan Pegasos II
powernv10            IBM PowerNV (Non-Virtualized) POWER10
powernv8             IBM PowerNV (Non-Virtualized) POWER8
powernv              IBM PowerNV (Non-Virtualized) POWER9 (alias of  powernv9)
powernv9             IBM PowerNV (Non-Virtualized) POWER9
ppce500              generic paravirt e500 platform
pseries-2.1          pSeries Logical Partition (PAPR compliant)
[lots of different pseries versions omitted here]
pseries              pSeries Logical Partition (PAPR compliant) (alias of pseries-8.0)
pseries-8.0          pSeries Logical Partition (PAPR compliant) (default)
ref405ep             ref405ep
sam460ex             aCube Sam460ex
virtex-ml507         Xilinx Virtex ML507 reference design

It makes no sense to define it for qemu-system-ppc as that version does 
not have G5 and 64 bit CPUs compiled in. Cf. qemu-system-ppc -cpu help and 
qemu-system-ppc64 -cpu help or target/ppc/cpu-models.c so I don't know 
what you're talking about.

>>> Secondly it's not clear to me why you've chosen names like "powermac_3_1" 
>>> instead of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP 
>>> Sawtooth model? For QEMU it is always best to emulate real machines, and 
>>> whilst I understand you want to separate out the two versions of the mac99 
>>> machine, having "powermac_X_Y" seems less clear to me.
>> 
>> These machine model identifiers are used by Apple to uniquely identify (all 
>> of) their machines since new-world Macs (even modern iPads and Macs have 
>> them) so for Mac people this should be clearer than the informal names that 
>> could get a bit long and confusing as there may be slight differences 
>> within a family. In any case, qemu-system-ppc -M mac99 is not corresponding 
>> to any real Mac so I'd like the options which do emulate real Macs to be 
>> called in a name that show which Mac is that. For the PPC Macs there's some 
>> info here for example:
>> 
>> https://en.wikipedia.org/wiki/Power_Mac_G4
>> 
>> And everymac.com also has info on all Macs. There were actually more than 
>> one G4 PowerMac with AGP but the other one was informally called gigabit 
>> ethernet. So the model ID is a shorter and better way to clearly identify 
>> which hardware is it (and it's also referenced in the device-tree of these 
>> Macs).
>
> Are you planning to work on different types of G4 Mac where this could be 
> confusing? Even to me "PowerMac 3.1" doesn't really tell me what model of Mac 
> is being emulated, whereas "g4agp" (much in the same way as g3beige) is much 
> more friendlier to people interested in using QEMU for Mac emulation.

This is similar problem as some people like to call Mac OS X versions by 
number and some by big cats names. Personally I prefer version numbers 
because it's easy to tell which is newer or older that way without 
remembering a nomenclature or having to look it up every time. It would be 
good if others interested in this also shared their preference because if 
it's only us two with different views then it's hard to make a decision. I 
still think machine ID is better also because then these machines would be 
grouped in the -machine help output like the others but as long as we 
don't have other machines that start with a g or other Macs that have some 
other name it might work so I could change the naming if that's all needed 
for this to get in.

>>> Finally can you post links to the device trees that you are using for each 
>>> of the new machine types so that we have a clear reference point for 
>>> future changes to the QEMU Mac machines? Even better include the links in 
>>> the comments for each machine so that the information is easily visible 
>>> for developers.
>> 
>> I still have those I've posted over the past 8 years when I made changes to 
>> OpenBIOS to make the device-tree closer to real machine. I've downloaded it 
>> back then, don't know where to find it now but searching for e.g. 
>> "PowerMac3,1" "device-tree" should get some results.
>
> Nothing shows up for me, I'm afraid (remember that Google searches are unique 
> to each user). If you want argue for changing the QEMU machines, then we 
> should agree on the reference device model for future changes.

Sigh, maybe search your list archives instead of Googls. Also it's 
"PowerMac3,1" where I've converted the comma to underscre for qemu command 
line parsing so became powermac3_1 not powermac_3_1. Try searching with 
quotes to reduce the number of false results.

- mac99 (via=cuda) does not exist so no real device tree for this needed

- powermac3_1 (currently mac99,via=pmu) I've sent links years ago e.g.:
https://mail.coreboot.org/pipermail/openbios/2016-February/009145.html
but you still keep asking

- powermac7_3 (ppc64 mac99) The expected hardware is listed in a comment 
in mac_newworld.c also it adds a 970fx CPU and according to 
https://en.wikipedia.org/wiki/Power_Mac_G5 PowerMac7,3 was the first 
version with 970fx so I think that was the target for whoever started it 
back then. These G5 Macs are probably still around so you should be able 
to ask someone to get a device tree dump, I've only seen Linux hardware 
listings:
https://gist.github.com/tomari/3689297 
https://forum.ubuntu-fr.org/viewtopic.php?id=2026003 (last post)

-powerbook3_2 (mac99,via=pmi-adb) this is rare as Macs with PMU usually 
have USB and not ADB; only the first PowerBooks had an ADB trackpad (but 
no outside ports AFAIK). All other Macs with ADB had CUDA so I'm not even 
sure we need this option but if we want it then the first PowerBooks are 
candidates, I've picked the lowest number for 1st gen Titanium PowerBook 
from here:
https://en.wikipedia.org/wiki/PowerBook_G4
and e.g. these links confirm it had ADB:
https://forums.freebsd.org/threads/12-powerbook-g4-867mhz-xorg-doesnt-work.37815/
http://macos9lives.com/smforum/index.php/topic,4781.msg41380.html?PHPSESSID=75b23dcb4c042b51c6dddd311cff2341#msg41380

It would be tough to come up with a name for the powerbook3_2 though as 
these were called Early 2001 Titanium PowerBook G4 or code name Mercury 
but even Mac fanatics probably couldn't tell that was a powerbook if you 
call it g4mercury so I'm open to votes on naming but hard to be convinced 
there's anything simpler and more straightforward than using machine id 
which is usually also listed everywhere for these.

Regards,
BALATON Zoltan

Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[Josh Juran]

On Jan 22, 2023, at 4:48 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:

> It would be tough to come up with a name for the powerbook3_2 though as these were called Early 2001 Titanium PowerBook G4 or code name Mercury but even Mac fanatics probably couldn't tell that was a powerbook if you call it g4mercury so I'm open to votes on naming but hard to be convinced there's anything simpler and more straightforward than using machine id which is usually also listed everywhere for these.

g4tibook1stgen?

("TiBook" being an affectionate abbreviation for "Titanium PowerBook")

Cheers,
Josh

Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[Mark Cave-Ayland]

On 22/01/2023 21:48, BALATON Zoltan wrote:

> On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
>> On 11/01/2023 00:36, BALATON Zoltan wrote:
>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>>> On 04/01/2023 21:59, 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.
>>>>>
>>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>>
>>>> Some thoughts on this: the first is that not everyone agrees that for 
>>>> qemu-system-X that X represents the target. There were previous discussion where 
>>>> some KVM people assumed X represented the host, i.e. ppc64 was the binary that 
>>>> ran all PPC guests but with hardware acceleration for ppc64 guests on ppc64 
>>>> hosts. This was a while ago, so it may be worth starting a thread on qemu-devel 
>>>> to see what the current consensus is.
>>>
>>> I don't see how this is relevant to this series, Also likely not the case any more 
>>> as qemu-system-ppc and qemu-system-ppc64 share most of the code since a while with 
>>> ppc64 including the config of ppc and adding more machines.
>>
>> Well the patch defines the powermac 7.3 machine just for TARGET_PPC64, no? So 
>> you're making the assumption qemu-system-ppc64 represents a 64-bit target rather 
>> than a 64-bit host.
> 
> I'm not making that assumption, it's already there:
> 
> $ qemu-system-ppc -machine help
> Supported machines are:
> 40p                  IBM RS/6000 7020 (40p)
> bamboo               bamboo
> g3beige              Heathrow based PowerMAC (default)
> mac99                Mac99 based PowerMAC
> mpc8544ds            mpc8544ds
> none                 empty machine
> pegasos2             Genesi/bPlan Pegasos II
> ppce500              generic paravirt e500 platform
> ref405ep             ref405ep
> sam460ex             aCube Sam460ex
> virtex-ml507         Xilinx Virtex ML507 reference design
> 
> $ qemu-system-ppc64 -machine help
> Supported machines are:
> 40p                  IBM RS/6000 7020 (40p)
> bamboo               bamboo
> g3beige              Heathrow based PowerMAC
> mac99                Mac99 based PowerMAC
> mpc8544ds            mpc8544ds
> none                 empty machine
> pegasos2             Genesi/bPlan Pegasos II
> powernv10            IBM PowerNV (Non-Virtualized) POWER10
> powernv8             IBM PowerNV (Non-Virtualized) POWER8
> powernv              IBM PowerNV (Non-Virtualized) POWER9 (alias of  powernv9)
> powernv9             IBM PowerNV (Non-Virtualized) POWER9
> ppce500              generic paravirt e500 platform
> pseries-2.1          pSeries Logical Partition (PAPR compliant)
> [lots of different pseries versions omitted here]
> pseries              pSeries Logical Partition (PAPR compliant) (alias of pseries-8.0)
> pseries-8.0          pSeries Logical Partition (PAPR compliant) (default)
> ref405ep             ref405ep
> sam460ex             aCube Sam460ex
> virtex-ml507         Xilinx Virtex ML507 reference design
> 
> It makes no sense to define it for qemu-system-ppc as that version does not have G5 
> and 64 bit CPUs compiled in. Cf. qemu-system-ppc -cpu help and qemu-system-ppc64 -cpu 
> help or target/ppc/cpu-models.c so I don't know what you're talking about.

I did a quick ask around online, and the general consensus was that it references the 
target (see https://lists.gnu.org/archive/html/qemu-devel/2022-05/msg00757.html for 
one of the more recent discussions about this as why this isn't always clear). 
However as you point out the 64-bit CPU isn't available for qemu-system-ppc so you're 
right that won't be an issue here.

>>>> Secondly it's not clear to me why you've chosen names like "powermac_3_1" instead 
>>>> of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth model? For 
>>>> QEMU it is always best to emulate real machines, and whilst I understand you want 
>>>> to separate out the two versions of the mac99 machine, having "powermac_X_Y" 
>>>> seems less clear to me.
>>>
>>> These machine model identifiers are used by Apple to uniquely identify (all of) 
>>> their machines since new-world Macs (even modern iPads and Macs have them) so for 
>>> Mac people this should be clearer than the informal names that could get a bit 
>>> long and confusing as there may be slight differences within a family. In any 
>>> case, qemu-system-ppc -M mac99 is not corresponding to any real Mac so I'd like 
>>> the options which do emulate real Macs to be called in a name that show which Mac 
>>> is that. For the PPC Macs there's some info here for example:
>>>
>>> https://en.wikipedia.org/wiki/Power_Mac_G4
>>>
>>> And everymac.com also has info on all Macs. There were actually more than one G4 
>>> PowerMac with AGP but the other one was informally called gigabit ethernet. So the 
>>> model ID is a shorter and better way to clearly identify which hardware is it (and 
>>> it's also referenced in the device-tree of these Macs).
>>
>> Are you planning to work on different types of G4 Mac where this could be 
>> confusing? Even to me "PowerMac 3.1" doesn't really tell me what model of Mac is 
>> being emulated, whereas "g4agp" (much in the same way as g3beige) is much more 
>> friendlier to people interested in using QEMU for Mac emulation.
> 
> This is similar problem as some people like to call Mac OS X versions by number and 
> some by big cats names. Personally I prefer version numbers because it's easy to tell 
> which is newer or older that way without remembering a nomenclature or having to look 
> it up every time. It would be good if others interested in this also shared their 
> preference because if it's only us two with different views then it's hard to make a 
> decision. I still think machine ID is better also because then these machines would 
> be grouped in the -machine help output like the others but as long as we don't have 
> other machines that start with a g or other Macs that have some other name it might 
> work so I could change the naming if that's all needed for this to get in.

I'd lean towards the g* naming, because not only is it more obvious to less technical 
Mac users what is being emulated, it matches the existing precedent set by g3beige.

>>>> Finally can you post links to the device trees that you are using for each of the 
>>>> new machine types so that we have a clear reference point for future changes to 
>>>> the QEMU Mac machines? Even better include the links in the comments for each 
>>>> machine so that the information is easily visible for developers.
>>>
>>> I still have those I've posted over the past 8 years when I made changes to 
>>> OpenBIOS to make the device-tree closer to real machine. I've downloaded it back 
>>> then, don't know where to find it now but searching for e.g. "PowerMac3,1" 
>>> "device-tree" should get some results.
>>
>> Nothing shows up for me, I'm afraid (remember that Google searches are unique to 
>> each user). If you want argue for changing the QEMU machines, then we should agree 
>> on the reference device model for future changes.
> 
> Sigh, maybe search your list archives instead of Googls. Also it's "PowerMac3,1" 
> where I've converted the comma to underscre for qemu command line parsing so became 
> powermac3_1 not powermac_3_1. Try searching with quotes to reduce the number of false 
> results.
> 
> - mac99 (via=cuda) does not exist so no real device tree for this needed
> 
> - powermac3_1 (currently mac99,via=pmu) I've sent links years ago e.g.:
> https://mail.coreboot.org/pipermail/openbios/2016-February/009145.html
> but you still keep asking

Right, because old documentation like this is slowly disappearing from the internet. 
We should consider a patch to add those public links into the source files so there 
is a (hopefully) long-term reference to them.

> - powermac7_3 (ppc64 mac99) The expected hardware is listed in a comment in 
> mac_newworld.c also it adds a 970fx CPU and according to 
> https://en.wikipedia.org/wiki/Power_Mac_G5 PowerMac7,3 was the first version with 
> 970fx so I think that was the target for whoever started it back then. These G5 Macs 
> are probably still around so you should be able to ask someone to get a device tree 
> dump, I've only seen Linux hardware listings:
> https://gist.github.com/tomari/3689297 
> https://forum.ubuntu-fr.org/viewtopic.php?id=2026003 (last post)
> 
> -powerbook3_2 (mac99,via=pmi-adb) this is rare as Macs with PMU usually have USB and 
> not ADB; only the first PowerBooks had an ADB trackpad (but no outside ports AFAIK). 
> All other Macs with ADB had CUDA so I'm not even sure we need this option but if we 
> want it then the first PowerBooks are candidates, I've picked the lowest number for 
> 1st gen Titanium PowerBook from here:
> https://en.wikipedia.org/wiki/PowerBook_G4
> and e.g. these links confirm it had ADB:
> https://forums.freebsd.org/threads/12-powerbook-g4-867mhz-xorg-doesnt-work.37815/
> http://macos9lives.com/smforum/index.php/topic,4781.msg41380.html?PHPSESSID=75b23dcb4c042b51c6dddd311cff2341#msg41380 
> 
> 
> It would be tough to come up with a name for the powerbook3_2 though as these were 
> called Early 2001 Titanium PowerBook G4 or code name Mercury but even Mac fanatics 
> probably couldn't tell that was a powerbook if you call it g4mercury so I'm open to 
> votes on naming but hard to be convinced there's anything simpler and more 
> straightforward than using machine id which is usually also listed everywhere for these.

The question really is which OSs use -M mac99,via=cuda and -M mac99,via=pmu-adb, and 
what real machines were intended to boot them. Howard, perhaps you have better 
knowledge of this?


ATB,

Mark.

Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs

[BALATON Zoltan]

On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
> On 22/01/2023 21:48, BALATON Zoltan wrote:
>> On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
>>> On 11/01/2023 00:36, BALATON Zoltan wrote:
>>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>>>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>>>> Secondly it's not clear to me why you've chosen names like 
>>>>> "powermac_3_1" instead of "g4agp"? Does powermac_3_1 uniquely identify 
>>>>> the G4 AGP Sawtooth model? For QEMU it is always best to emulate real 
>>>>> machines, and whilst I understand you want to separate out the two 
>>>>> versions of the mac99 machine, having "powermac_X_Y" seems less clear to 
>>>>> me.
>>>> 
>>>> These machine model identifiers are used by Apple to uniquely identify 
>>>> (all of) their machines since new-world Macs (even modern iPads and Macs 
>>>> have them) so for Mac people this should be clearer than the informal 
>>>> names that could get a bit long and confusing as there may be slight 
>>>> differences within a family. In any case, qemu-system-ppc -M mac99 is not 
>>>> corresponding to any real Mac so I'd like the options which do emulate 
>>>> real Macs to be called in a name that show which Mac is that. For the PPC 
>>>> Macs there's some info here for example:
>>>> 
>>>> https://en.wikipedia.org/wiki/Power_Mac_G4
>>>> 
>>>> And everymac.com also has info on all Macs. There were actually more than 
>>>> one G4 PowerMac with AGP but the other one was informally called gigabit 
>>>> ethernet. So the model ID is a shorter and better way to clearly identify 
>>>> which hardware is it (and it's also referenced in the device-tree of 
>>>> these Macs).
>>> 
>>> Are you planning to work on different types of G4 Mac where this could be 
>>> confusing? Even to me "PowerMac 3.1" doesn't really tell me what model of 
>>> Mac is being emulated, whereas "g4agp" (much in the same way as g3beige) 
>>> is much more friendlier to people interested in using QEMU for Mac 
>>> emulation.
>> 
>> This is similar problem as some people like to call Mac OS X versions by 
>> number and some by big cats names. Personally I prefer version numbers 
>> because it's easy to tell which is newer or older that way without 
>> remembering a nomenclature or having to look it up every time. It would be 
>> good if others interested in this also shared their preference because if 
>> it's only us two with different views then it's hard to make a decision. I 
>> still think machine ID is better also because then these machines would be 
>> grouped in the -machine help output like the others but as long as we don't 
>> have other machines that start with a g or other Macs that have some other 
>> name it might work so I could change the naming if that's all needed for 
>> this to get in.
>
> I'd lean towards the g* naming, because not only is it more obvious to less 
> technical Mac users what is being emulated, it matches the existing precedent 
> set by g3beige.

The g3beige is not a good example as model ids were introduced with new 
world Macs and the beige G3 is one of the last old world ones which had a 
numeric ID so we can't give that a name by model ID. All later Macs though 
have a model ID which is a short and clear way to idenfify a model. Found 
a list here:

https://www.macupgrades.co.uk/store/mac_model_id/

and it even carries on for modern Macs:

https://support.apple.com/en-us/HT201634

and it's listed in System Profiler next to the model name:

https://support.apple.com/en-gb/HT201581

so it should be pretty obvious and familiar to Mac users. So I think 
anything else would be more confusing but I don't care that much as long 
as we can have a separate name for each machine we emulate. I'll take 
whatever names you come up with if that's what it takes for this patch to 
get merged. Please tell me what names you want and I'll change it if 
nobody else votes fot the names I've proposed.

Regards,
BALATON Zoltan

[PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU

[BALATON Zoltan]

Besides resolving the confusing behaviour mentioned in previous commit
this might also allow unifying qemu-system-ppc and qemu-system-ppc64
in the future.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
 hw/ppc/mac_newworld.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 3f5d1ec097..f07c37328b 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -165,6 +165,12 @@ static void ppc_core99_init(MachineState *machine)
         qemu_register_reset(ppc_core99_reset, cpu);
     }
 
+    if (object_property_find(OBJECT(machine), "via")) {
+        if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
+            warn_report("mac99 with G5 CPU is deprecated, "
+                        "use powermac7_3 instead");
+        }
+    }
     /* allocate RAM */
     if (machine->ram_size > 2 * GiB) {
         error_report("RAM size more than 2 GiB is not supported");
-- 
2.30.6

Re: [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU

[Philippe Mathieu-Daudé]

On 4/1/23 22:59, BALATON Zoltan wrote:
> Besides resolving the confusing behaviour mentioned in previous commit
> this might also allow unifying qemu-system-ppc and qemu-system-ppc64
> in the future.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>   hw/ppc/mac_newworld.c | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 3f5d1ec097..f07c37328b 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -165,6 +165,12 @@ static void ppc_core99_init(MachineState *machine)
>           qemu_register_reset(ppc_core99_reset, cpu);
>       }
>   
> +    if (object_property_find(OBJECT(machine), "via")) {
> +        if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
> +            warn_report("mac99 with G5 CPU is deprecated, "
> +                        "use powermac7_3 instead");

"mac99 machine with G5 CPU is deprecated, prefer the powermac7_3 machine 
instead"?

> +        }
> +    }
>       /* allocate RAM */
>       if (machine->ram_size > 2 * GiB) {
>           error_report("RAM size more than 2 GiB is not supported");

Re: [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Thu, 5 Jan 2023, Philippe Mathieu-Daudé wrote:
> On 4/1/23 22:59, BALATON Zoltan wrote:
>> Besides resolving the confusing behaviour mentioned in previous commit
>> this might also allow unifying qemu-system-ppc and qemu-system-ppc64
>> in the future.
>> 
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>>   hw/ppc/mac_newworld.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>> 
>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>> index 3f5d1ec097..f07c37328b 100644
>> --- a/hw/ppc/mac_newworld.c
>> +++ b/hw/ppc/mac_newworld.c
>> @@ -165,6 +165,12 @@ static void ppc_core99_init(MachineState *machine)
>>           qemu_register_reset(ppc_core99_reset, cpu);
>>       }
>>   +    if (object_property_find(OBJECT(machine), "via")) {
>> +        if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
>> +            warn_report("mac99 with G5 CPU is deprecated, "
>> +                        "use powermac7_3 instead");
>
> "mac99 machine with G5 CPU is deprecated, prefer the powermac7_3 machine 
> instead"?

I don't mind what the text is but this seems unnecessarily long where my 
version conveys the message in a more concise way. But if others prefer 
something else I'm OK to change it as you like. I expect these last 
patches may need to be repartitioned so I'm waiting for review to see 
what's preferred.

Regards,
BALATON Zoltan

>> +        }
>> +    }
>>       /* allocate RAM */
>>       if (machine->ram_size > 2 * GiB) {
>>           error_report("RAM size more than 2 GiB is not supported");
>
>
>

[PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

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>
---
 hw/ppc/mac_newworld.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index f07c37328b..adf185bd3a 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
         if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
             warn_report("mac99 with G5 CPU is deprecated, "
                         "use powermac7_3 instead");
+        } else {
+            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
+                warn_report("mac99,via=pmu is deprecated, "
+                            "use powermac3_1 instead");
+            }
+            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
+                warn_report("mac99,via=pmu-adb is deprecated, "
+                            "use powerbook3_2 instead");
+            }
         }
     }
     /* allocate RAM */
-- 
2.30.6

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Philippe Mathieu-Daudé]

On 4/1/23 22: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>
> ---
>   hw/ppc/mac_newworld.c | 9 +++++++++
>   1 file changed, 9 insertions(+)

Don't we need to document in the 'System emulator machines'
section of docs/about/deprecated.rst? (maybe within a
"machine options" subsection)

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Thu, 5 Jan 2023, Philippe Mathieu-Daudé wrote:
> On 4/1/23 22: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>
>> ---
>>   hw/ppc/mac_newworld.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>
> Don't we need to document in the 'System emulator machines'
> section of docs/about/deprecated.rst? (maybe within a
> "machine options" subsection)

That's in patch 7 for now which contains all the docs updates in one 
patch, I can reorganise these once we decide what should each patch 
contain. Options could be to make all deprecations a single patch or 
divide it by machines or options like one patch for ppc64 mac99 another 
for via option os whatever Matk is ready to accept at the end.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Mark Cave-Ayland]

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.

> ---
>   hw/ppc/mac_newworld.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index f07c37328b..adf185bd3a 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
>           if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
>               warn_report("mac99 with G5 CPU is deprecated, "
>                           "use powermac7_3 instead");
> +        } else {
> +            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
> +                warn_report("mac99,via=pmu is deprecated, "
> +                            "use powermac3_1 instead");
> +            }
> +            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
> +                warn_report("mac99,via=pmu-adb is deprecated, "
> +                            "use powerbook3_2 instead");
> +            }
>           }
>       }
>       /* allocate RAM */


ATB,

Mark.

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

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.

Regards,
BALATON Zoltan

>> ---
>>   hw/ppc/mac_newworld.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>> 
>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>> index f07c37328b..adf185bd3a 100644
>> --- a/hw/ppc/mac_newworld.c
>> +++ b/hw/ppc/mac_newworld.c
>> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
>>           if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
>>               warn_report("mac99 with G5 CPU is deprecated, "
>>                           "use powermac7_3 instead");
>> +        } else {
>> +            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
>> +                warn_report("mac99,via=pmu is deprecated, "
>> +                            "use powermac3_1 instead");
>> +            }
>> +            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
>> +                warn_report("mac99,via=pmu-adb is deprecated, "
>> +                            "use powerbook3_2 instead");
>> +            }
>>           }
>>       }
>>       /* allocate RAM */
>
>
> ATB,
>
> Mark.
>
>

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]

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.



>
> >> ---
> >>   hw/ppc/mac_newworld.c | 9 +++++++++
> >>   1 file changed, 9 insertions(+)
> >>
> >> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> >> index f07c37328b..adf185bd3a 100644
> >> --- a/hw/ppc/mac_newworld.c
> >> +++ b/hw/ppc/mac_newworld.c
> >> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
> >>           if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
> >>               warn_report("mac99 with G5 CPU is deprecated, "
> >>                           "use powermac7_3 instead");
> >> +        } else {
> >> +            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
> >> +                warn_report("mac99,via=pmu is deprecated, "
> >> +                            "use powermac3_1 instead");
> >> +            }
> >> +            if (core99_machine->via_config ==
> CORE99_VIA_CONFIG_PMU_ADB) {
> >> +                warn_report("mac99,via=pmu-adb is deprecated, "
> >> +                            "use powerbook3_2 instead");
> >> +            }
> >>           }
> >>       }
> >>       /* allocate RAM */
> >
> >
> > ATB,
> >
> > Mark.
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 4141 bytes --]

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

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

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.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 5636 bytes --]

On Fri, Jan 13, 2023 at 12:53 AM BALATON Zoltan <balaton@eik.bme.hu> 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:
>
>
No, I haven't forgotten that discussion. FWIW (as I cannot contribute): I
personally do not oppose a name change, the new names seem more
descriptive. I tested your patches and they behave as they should. The
functionality does not change. However, my simple point was what's in a
name when the underlying machine does not reflect what the name implies.

It is not my place to comment on a possible development agenda. I can only
tell you what I'd like and point out issues.



> - 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
>
> 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.
>

It is not about passing through USB devices and active packets per
endpoint. The powermac3,1 has two 2 USB 1.1 ports. However, when booting
Mac OS 9.0.4 with via=pmu it will support only one (the kbd).  When started
with via=cuda -usb -device usb-kbd -device usb-mouse it will support the
first-mentioned usb-kbd. When kbd and mouse arguments are reversed it
supports the other device ;-)


>
> 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.
>
> Regards,
> BALATON Zoltan
>

[-- Attachment #2: Type: text/html, Size: 7666 bytes --]

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Fri, 13 Jan 2023, Howard Spoelstra wrote:
> On Fri, Jan 13, 2023 at 12:53 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> 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:
>>
> No, I haven't forgotten that discussion. FWIW (as I cannot contribute): I
> personally do not oppose a name change, the new names seem more
> descriptive. I tested your patches and they behave as they should. The
> functionality does not change. However, my simple point was what's in a
> name when the underlying machine does not reflect what the name implies.

In case of powermac3_1 (currently mac99,via=pmu) it does resemble the 
PowerMac3,1 G4 AGP machine. It's also what the device tree says and the 
emulated hardware corresponds to that machine, apart from some missing 
pieces (like I2C) and known bugs in some (like USB) it aims to emulate 
that machine but it's currently hidden in the obscure via option of mac99 
which ny default is some non-existent Mac like machine with cuda. It's 
much easier for users not having inside knowledge of QEMU to get a machine 
type which clearly says what it emulates. If we ever want to run firmware 
ROM from the real machine we also want to make sure we emulate a real 
machine. I've done some steps in that direction before and submitted RFC 
patches that could get to an OF prompt with some debugger tweaking and 
could eventually made to work but it needs Mark's screamer series to get 
finished and some rewrite of the macio emulation to add I2C cleanly so 
it's stalled currently but maybe one day we'll get there.

For powermac7,3 it is what qemu-system-ppc64 -M mac99 currently aims to 
emulate evidenced by the comment at the beginning and that it adds U3 
chipset instead of Uninorth but currently only Linux boots on this 
machine. It may need some more fixes to get other OSes running starting 
with the device tree. I think the way for that is to move device tree 
creation to QEMU similar to what other PPC machines do. I have plans for 
that but it's blocked by not being able to contribute to OpenBIOS as most 
of my patches are disliked by Mark but I'll keep trying.

The powerboot3,2 is one hardware I could find info on having PMU and ADB 
and it's the same era as the PowerMac3,1 so has similar hardware but not 
sure why this combination is even there. What guest needs this that cannot 
run with either mac99 or powermac3,1?

> It is not my place to comment on a possible development agenda. I can only
> tell you what I'd like and point out issues.
>
>> - 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
>>
>> 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.
>>
>
> It is not about passing through USB devices and active packets per
> endpoint. The powermac3,1 has two 2 USB 1.1 ports. However, when booting
> Mac OS 9.0.4 with via=pmu it will support only one (the kbd).  When started
> with via=cuda -usb -device usb-kbd -device usb-mouse it will support the
> first-mentioned usb-kbd. When kbd and mouse arguments are reversed it
> supports the other device ;-)

Is this something that happens on real hardware as well or is it some bug 
in emulation somewhere? If the drivers on this OS keep active packets on 
different endpoints then it's the same issue we've discovered with USB 
pass through of audio devices that also need this feature. If it's 
something else it may be fixable but we need to understand first what 
causes the issue.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Mark Cave-Ayland]

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
> 
> 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.

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 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.


ATB,

Mark.

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

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
>> 
>> 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?

> 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.

> 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.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Mark Cave-Ayland]

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.

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.

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 9962 bytes --]

On Mon, Jan 23, 2023 at 11:06 PM Mark Cave-Ayland <
mark.cave-ayland@ilande.co.uk> wrote:

> 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
See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC

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.
>

[-- Attachment #2: Type: text/html, Size: 12850 bytes --]

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> 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.

And do these OSes run on real PowerMac3,1? If so then we likely have a bug 
in USB emulation so maybe that could be fixed? In any case my patch does 
not change mac99 and this should continue to work.

> 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.

Since via=pmu is what should be a real machine does it run OS X >=10.2 
already?

> 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
> See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC

That doc might need some updating. It seems to be from before pegasos2 was 
added. Maybe we would be better off linking from this page to others that 
are more actively maintained such as: 
https://www.emaculation.com/doku.php/qemu 
and 
http://zero.eik.bme.hu/~balaton/qemu/amiga/

or even better updating the main docs in

https://www.qemu.org/docs/master/system/ppc/powermac.html

or somehow link these sources together.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]

On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> > 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.
>
> And do these OSes run on real PowerMac3,1? If so then we likely have a bug
> in USB emulation so maybe that could be fixed? In any case my patch does
> not change mac99 and this should continue to work.
>
> > 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.
>
> Since via=pmu is what should be a real machine does it run OS X >=10.2
> already?
>

A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11

qemu-system-ppc status:
8.6 will not boot from CD or HD.
9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2
usb device problem
9.1 and 9.2 with via=pmu
10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also with
an usb problem)
10.2 with via=pmu (but has serious graphics speed problem, also with
via=cuda)
10.3 and 10.4 with via=pmu
10.5 only with via=pmu (but needs the 900Mhz speed hack).

*9.0.4 will only run with Mac OS Rom version 5.2.1 and above.

It seems via=pmu provides usb mouse first, usb kbd second.
With Mac OS 9.0.4 the second device will not work.
With 10.0 / 10.1 both usb mouse and kbd do not work.

Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by default I
only see one bus: USB 0 into which both mouse and kdb are plugged.
On the real G4 the mouse and kbd are each plugged into another bus, so I
see the kbd on e.g. USB 0 and the mouse on e.g. USB 1.

With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus"
We can add a second USB bus with e.g. -device pci-ohci,id=usb1  (this is
the Apple USB controller).

Then add mouse and kbd to different buses with:
-device usb-mouse,bus=usb-bus.0    (attaches to first and default bus)
-device usb-kbd,bus=usb1.0 (attaches to second bus).

This then mimics what I see on real hardware. Should qemu-system-ppc by
default provide the same?



> > 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
> > See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC
>
> That doc might need some updating. It seems to be from before pegasos2 was
> added. Maybe we would be better off linking from this page to others that
> are more actively maintained such as:
> https://www.emaculation.com/doku.php/qemu
> and
> http://zero.eik.bme.hu/~balaton/qemu/amiga/
>
>
I "maintain" that page with only general information. I can link to the
specific sites you mention.


> or even better updating the main docs in
>
> https://www.qemu.org/docs/master/system/ppc/powermac.html
>
>
That would have to be taken up by someone else.

Best,
Howard

[-- Attachment #2: Type: text/html, Size: 4818 bytes --]

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> On Tue, 24 Jan 2023, Howard Spoelstra wrote:
>>> 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.
>>
>> And do these OSes run on real PowerMac3,1? If so then we likely have a bug
>> in USB emulation so maybe that could be fixed? In any case my patch does
>> not change mac99 and this should continue to work.
>>
>>> 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.
>>
>> Since via=pmu is what should be a real machine does it run OS X >=10.2
>> already?
>>
>
> A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11
>
> qemu-system-ppc status:
> 8.6 will not boot from CD or HD.
> 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2
> usb device problem
> 9.1 and 9.2 with via=pmu
> 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also with
> an usb problem)
> 10.2 with via=pmu (but has serious graphics speed problem, also with
> via=cuda)
> 10.3 and 10.4 with via=pmu
> 10.5 only with via=pmu (but needs the 900Mhz speed hack).
>
> *9.0.4 will only run with Mac OS Rom version 5.2.1 and above.

I thought MacOS 8 needed old world ROM but looks like it can also load it 
from disk on new world machines. Then what version of the ROM it has? 
It seems there was some change at ROM 5.2.1 then which solves the problem 
with usb and older versions may have done something differently and 
expect it to work unlike it's emulated now.

So it seems versions before 10.2 have a problem (except 9,1 and 9.2 which 
may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I assume 
later 9.x versions have at least this or newer Toolbox ROM) I think it's 
esasier to debug with OS X because it's easier to get logs and the drivers 
may also be open source so easier to check what's happening so let's just 
forget about MacOS9 for now and try to find out what changed between 10.1 
and 10.2 in usb handling.

> It seems via=pmu provides usb mouse first, usb kbd second.
> With Mac OS 9.0.4 the second device will not work.
> With 10.0 / 10.1 both usb mouse and kbd do not work.

These are added here:

https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435

you could change the order but it does not matter if both needs to work. 
If it makes the first one work then maybe the older USB drivers only 
handle one port per bus? But then the problem in OS X may be different.

> Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by default I
> only see one bus: USB 0 into which both mouse and kdb are plugged.
> On the real G4 the mouse and kbd are each plugged into another bus, so I
> see the kbd on e.g. USB 0 and the mouse on e.g. USB 1.
>
> With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus"
> We can add a second USB bus with e.g. -device pci-ohci,id=usb1  (this is
> the Apple USB controller).
>
> Then add mouse and kbd to different buses with:
> -device usb-mouse,bus=usb-bus.0    (attaches to first and default bus)
> -device usb-kbd,bus=usb1.0 (attaches to second bus).
>
> This then mimics what I see on real hardware. Should qemu-system-ppc by
> default provide the same?

Does this solve the problem you have? (You talk about via=cude above but I 
think it should be via=pmu. Is that a typo?) If this helps mac_newworld.c 
could add another usb bus or do somerthing different to match real 
hardware but you have to convince Mark about that first... Also Mac 
keyboards have a hub where the mouse is usially connected. Does modeling 
that setup with QEMU help?

Other idea you could try is to boot 10.1 and 10.2 and compare the ioteg 
outputs for the USB devices to see if there are some differences or get 
the USB driver versions and try to find out what changed in them.

>> or even better updating the main docs in
>>
>> https://www.qemu.org/docs/master/system/ppc/powermac.html
>>
> That would have to be taken up by someone else.

That page is generated from this file in QEMU source:

https://gitlab.com/qemu-project/qemu/-/blob/master/docs/system/ppc/powermac.rst

you can submit a patch to that like I did:

https://lists.nongnu.org/archive/html/qemu-ppc/2023-01/msg00006.html

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 6004 bytes --]

On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> > On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan <balaton@eik.bme.hu>
> wrote:
> >> On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> >>> 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.
> >>
> >> And do these OSes run on real PowerMac3,1? If so then we likely have a
> bug
> >> in USB emulation so maybe that could be fixed? In any case my patch does
> >> not change mac99 and this should continue to work.
> >>
> >>> 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.
> >>
> >> Since via=pmu is what should be a real machine does it run OS X >=10.2
> >> already?
> >>
> >
> > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11
> >
> > qemu-system-ppc status:
> > 8.6 will not boot from CD or HD.
> > 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2
> > usb device problem
> > 9.1 and 9.2 with via=pmu
> > 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also
> with
> > an usb problem)
> > 10.2 with via=pmu (but has serious graphics speed problem, also with
> > via=cuda)
> > 10.3 and 10.4 with via=pmu
> > 10.5 only with via=pmu (but needs the 900Mhz speed hack).
> >
> > *9.0.4 will only run with Mac OS Rom version 5.2.1 and above.
>
> I thought MacOS 8 needed old world ROM but looks like it can also load it
> from disk on new world machines. Then what version of the ROM it has?
> It seems there was some change at ROM 5.2.1 then which solves the problem
> with usb and older versions may have done something differently and
> expect it to work unlike it's emulated now.
>
> The rom on the 8.6 Cd is version ....
The disk utility on the CD cannot initialise a hard disk (something we had
with some 9.0.4 versions too)


> So it seems versions before 10.2 have a problem (except 9,1 and 9.2 which
> may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I assume
> later 9.x versions have at least this or newer Toolbox ROM) I think it's
> esasier to debug with OS X because it's easier to get logs and the drivers
> may also be open source so easier to check what's happening so let's just
> forget about MacOS9 for now and try to find out what changed between 10.1
> and 10.2 in usb handling.
>
> > It seems via=pmu provides usb mouse first, usb kbd second.
> > With Mac OS 9.0.4 the second device will not work.
> > With 10.0 / 10.1 both usb mouse and kbd do not work.
>
> These are added here:
>
>
> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435
>
> you could change the order but it does not matter if both needs to work.
> If it makes the first one work then maybe the older USB drivers only
> handle one port per bus? But then the problem in OS X may be different.
>
> > Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by
> default I
> > only see one bus: USB 0 into which both mouse and kdb are plugged.
> > On the real G4 the mouse and kbd are each plugged into another bus, so I
> > see the kbd on e.g. USB 0 and the mouse on e.g. USB 1.
> >
> > With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus"
> > We can add a second USB bus with e.g. -device pci-ohci,id=usb1  (this is
> > the Apple USB controller).
> >
> > Then add mouse and kbd to different buses with:
> > -device usb-mouse,bus=usb-bus.0    (attaches to first and default bus)
> > -device usb-kbd,bus=usb1.0 (attaches to second bus).
> >
> > This then mimics what I see on real hardware. Should qemu-system-ppc by
> > default provide the same?
>
> Does this solve the problem you have?


No.


> (You talk about via=cude above but I
> think it should be via=pmu. Is that a typo?)


No, even with via-cuda the first usb bus is created:
dev: pci-ohci, id ""
        masterbus = ""
        num-ports = 3 (0x3)
        firstport = 0 (0x0)
        addr = 0d.0
        romfile = ""
        romsize = 4294967295 (0xffffffff)
        rombar = 1 (0x1)
        multifunction = false
        x-pcie-lnksta-dllla = true
        x-pcie-extcap-init = true
        failover_pair_id = ""
        acpi-index = 0 (0x0)
        class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100)
        bar 0: mem at 0x80080000 [0x800800ff]
        bus: usb-bus.0
          type usb-bus

I now think in some cases the mouse falls back to adb when usb does not
work. Hence the wiggling/clicking that is needed to get 9.0.4 to get to the
desktop.
Can we disable usb-bus creation for via=cuda?


If this helps mac_newworld.c
> could add another usb bus or do somerthing different to match real
> hardware but you have to convince Mark about that first... Also Mac
> keyboards have a hub where the mouse is usially connected. Does modeling
> that setup with QEMU help?
>
> No, same issues with that.


> Other idea you could try is to boot 10.1 and 10.2 and compare the ioreg
> outputs for the USB devices to see if there are some differences or get
> the USB driver versions and try to find out what changed in them.
>
>
I attempted to take a look, but without mouse/kbd it is difficult to get to
ioreg ;-)



> >> or even better updating the main docs in
> >>
> >> https://www.qemu.org/docs/master/system/ppc/powermac.html
> >>
> > That would have to be taken up by someone else.
>
> That page is generated from this file in QEMU source:
>
>
> https://gitlab.com/qemu-project/qemu/-/blob/master/docs/system/ppc/powermac.rst
>
> you can submit a patch to that like I did:
>
> https://lists.nongnu.org/archive/html/qemu-ppc/2023-01/msg00006.html
>
> Regards,
> BALATON Zoltan
>

[-- Attachment #2: Type: text/html, Size: 8574 bytes --]

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> I thought MacOS 8 needed old world ROM but looks like it can also load it
>> from disk on new world machines. Then what version of the ROM it has?
>> It seems there was some change at ROM 5.2.1 then which solves the problem
>> with usb and older versions may have done something differently and
>> expect it to work unlike it's emulated now.
>>
>> The rom on the 8.6 Cd is version ....
> The disk utility on the CD cannot initialise a hard disk (something we had
> with some 9.0.4 versions too)

This sentence seems to be unfinished, also the disk utility problem is 
maybe unrelated so just ignore that for now and focus on usb first.

>> So it seems versions before 10.2 have a problem (except 9,1 and 9.2 which
>> may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I assume
>> later 9.x versions have at least this or newer Toolbox ROM) I think it's
>> esasier to debug with OS X because it's easier to get logs and the drivers
>> may also be open source so easier to check what's happening so let's just
>> forget about MacOS9 for now and try to find out what changed between 10.1
>> and 10.2 in usb handling.
>>
>>> It seems via=pmu provides usb mouse first, usb kbd second.
>>> With Mac OS 9.0.4 the second device will not work.
>>> With 10.0 / 10.1 both usb mouse and kbd do not work.
>>
>> These are added here:
>>
>>
>> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435
>>
>> you could change the order but it does not matter if both needs to work.
>> If it makes the first one work then maybe the older USB drivers only
>> handle one port per bus? But then the problem in OS X may be different.
>>
>>> Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by
>> default I
>>> only see one bus: USB 0 into which both mouse and kdb are plugged.
>>> On the real G4 the mouse and kbd are each plugged into another bus, so I
>>> see the kbd on e.g. USB 0 and the mouse on e.g. USB 1.
>>>
>>> With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus"
>>> We can add a second USB bus with e.g. -device pci-ohci,id=usb1  (this is
>>> the Apple USB controller).
>>>
>>> Then add mouse and kbd to different buses with:
>>> -device usb-mouse,bus=usb-bus.0    (attaches to first and default bus)
>>> -device usb-kbd,bus=usb1.0 (attaches to second bus).
>>>
>>> This then mimics what I see on real hardware. Should qemu-system-ppc by
>>> default provide the same?
>>
>> Does this solve the problem you have?
>
>
> No.

OK so then we should not do that by default either unless we find it's 
needed for some reason.

>> (You talk about via=cude above but I
>> think it should be via=pmu. Is that a typo?)
>
>
> No, even with via-cuda the first usb bus is created:
> dev: pci-ohci, id ""
>        masterbus = ""
>        num-ports = 3 (0x3)
>        firstport = 0 (0x0)
>        addr = 0d.0
>        romfile = ""
>        romsize = 4294967295 (0xffffffff)
>        rombar = 1 (0x1)
>        multifunction = false
>        x-pcie-lnksta-dllla = true
>        x-pcie-extcap-init = true
>        failover_pair_id = ""
>        acpi-index = 0 (0x0)
>        class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100)
>        bar 0: mem at 0x80080000 [0x800800ff]
>        bus: usb-bus.0
>          type usb-bus
>
> I now think in some cases the mouse falls back to adb when usb does not
> work. Hence the wiggling/clicking that is needed to get 9.0.4 to get to the
> desktop.
> Can we disable usb-bus creation for via=cuda?

Yes, try:

qemu-system-ppc -M mac99,usb=no

(I had to look at the code to find that out).

> If this helps mac_newworld.c
>> could add another usb bus or do somerthing different to match real
>> hardware but you have to convince Mark about that first... Also Mac
>> keyboards have a hub where the mouse is usially connected. Does modeling
>> that setup with QEMU help?
>>
>> No, same issues with that.

Then it's probably not about how these ports are arranged but something 
about modeiling the hardware maybe (i.e. QEMU does something differently 
than real hardware and this confuses the driver).

>> Other idea you could try is to boot 10.1 and 10.2 and compare the ioreg
>> outputs for the USB devices to see if there are some differences or get
>> the USB driver versions and try to find out what changed in them.
>>
>>
> I attempted to take a look, but without mouse/kbd it is difficult to get to
> ioreg ;-)

You can set up tap or vmnet network, boot it with cuda, enable ssh then 
you can access it from there after booting usb config. (It may even work 
with user network somehow, I think there's an option to forward a port 
from the guest to host then you could access ssh that way without having 
to set up bridged networking but you'll need to find that option as I 
don't remember what it was but I think I've seen it somewhere. Maybe in 
qemu-system-ppc -help or some docs on QEMU networking somewhere.)

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 7869 bytes --]

On Tue, Jan 24, 2023 at 4:33 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> > On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan <balaton@eik.bme.hu>
> wrote:
> >> I thought MacOS 8 needed old world ROM but looks like it can also load
> it
> >> from disk on new world machines. Then what version of the ROM it has?
> >> It seems there was some change at ROM 5.2.1 then which solves the
> problem
> >> with usb and older versions may have done something differently and
> >> expect it to work unlike it's emulated now.
> >>
> >> The rom on the 8.6 Cd is version ....
> > The disk utility on the CD cannot initialise a hard disk (something we
> had
> > with some 9.0.4 versions too)
>
> This sentence seems to be unfinished, also the disk utility problem is
> maybe unrelated so just ignore that for now and focus on usb first.
>
> >> So it seems versions before 10.2 have a problem (except 9,1 and 9.2
> which
> >> may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I
> assume
> >> later 9.x versions have at least this or newer Toolbox ROM) I think it's
> >> esasier to debug with OS X because it's easier to get logs and the
> drivers
> >> may also be open source so easier to check what's happening so let's
> just
> >> forget about MacOS9 for now and try to find out what changed between
> 10.1
> >> and 10.2 in usb handling.
> >>
> >>> It seems via=pmu provides usb mouse first, usb kbd second.
> >>> With Mac OS 9.0.4 the second device will not work.
> >>> With 10.0 / 10.1 both usb mouse and kbd do not work.
> >>
> >> These are added here:
> >>
> >>
> >>
> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435
> >>
> >> you could change the order but it does not matter if both needs to work.
> >> If it makes the first one work then maybe the older USB drivers only
> >> handle one port per bus? But then the problem in OS X may be different.
> >>
> >>> Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by
> >> default I
> >>> only see one bus: USB 0 into which both mouse and kdb are plugged.
> >>> On the real G4 the mouse and kbd are each plugged into another bus, so
> I
> >>> see the kbd on e.g. USB 0 and the mouse on e.g. USB 1.
> >>>
> >>> With -M mac99,via=cuda one USB bus is always created. It has id
> "usb-bus"
> >>> We can add a second USB bus with e.g. -device pci-ohci,id=usb1  (this
> is
> >>> the Apple USB controller).
> >>>
> >>> Then add mouse and kbd to different buses with:
> >>> -device usb-mouse,bus=usb-bus.0    (attaches to first and default bus)
> >>> -device usb-kbd,bus=usb1.0 (attaches to second bus).
> >>>
> >>> This then mimics what I see on real hardware. Should qemu-system-ppc by
> >>> default provide the same?
> >>
> >> Does this solve the problem you have?
> >
> >
> > No.
>
> OK so then we should not do that by default either unless we find it's
> needed for some reason.
>
> >> (You talk about via=cude above but I
> >> think it should be via=pmu. Is that a typo?)
> >
> >
> > No, even with via-cuda the first usb bus is created:
> > dev: pci-ohci, id ""
> >        masterbus = ""
> >        num-ports = 3 (0x3)
> >        firstport = 0 (0x0)
> >        addr = 0d.0
> >        romfile = ""
> >        romsize = 4294967295 (0xffffffff)
> >        rombar = 1 (0x1)
> >        multifunction = false
> >        x-pcie-lnksta-dllla = true
> >        x-pcie-extcap-init = true
> >        failover_pair_id = ""
> >        acpi-index = 0 (0x0)
> >        class USB controller, addr 00:0d.0, pci id 106b:003f (sub
> 1af4:1100)
> >        bar 0: mem at 0x80080000 [0x800800ff]
> >        bus: usb-bus.0
> >          type usb-bus
> >
> > I now think in some cases the mouse falls back to adb when usb does not
> > work. Hence the wiggling/clicking that is needed to get 9.0.4 to get to
> the
> > desktop.
> > Can we disable usb-bus creation for via=cuda?
>
> Yes, try:
>
> qemu-system-ppc -M mac99,usb=no
>
> (I had to look at the code to find that out).
>
> > If this helps mac_newworld.c
> >> could add another usb bus or do somerthing different to match real
> >> hardware but you have to convince Mark about that first... Also Mac
> >> keyboards have a hub where the mouse is usially connected. Does modeling
> >> that setup with QEMU help?
> >>
> >> No, same issues with that.
>
> Then it's probably not about how these ports are arranged but something
> about modeiling the hardware maybe (i.e. QEMU does something differently
> than real hardware and this confuses the driver).
>
> >> Other idea you could try is to boot 10.1 and 10.2 and compare the ioreg
> >> outputs for the USB devices to see if there are some differences or get
> >> the USB driver versions and try to find out what changed in them.
> >>
> >>
> > I attempted to take a look, but without mouse/kbd it is difficult to get
> to
> > ioreg ;-)
>


I tested all Mac OS/OSX available to me with mouse and kbd alternately
connected to usb-bus1 or usb-bus2.

./qemu-system-ppc \
-M mac99,usb=off \
-L pc-bios \
-boot c \
-prom-env "auto-boot?=true" \
-display gtk -monitor stdio \
-drive file=/home/hsp/Mac-disks/9.0.4.img,format=raw,media=disk \
-device pci-ohci,id=usb-bus1 \
-device pci-ohci,id=usb-bus2 \
-device usb-mouse,bus=usb-bus1.0,pcap=9.0.4_p1_mouse-2usb.pcap \
-device usb-kbd,bus=usb-bus2.0,pcap=9.0.4_p2_kbd-2usb.pcap \
-device sungem,netdev=network01 -netdev user,id=network01 \
-trace "usb_ohci*"

These are the results:

Mac OS:
#9.0.4 bus1 kbd: works up to usb_ohci_port_reset port #0 in trace, pcap
shows normal operation and recognition as HID device .
#9.0.4 bus2 mouse. Reverts to adb mouse. No recognition as HID device.
#9.0.4 bus1 mouse: usb_ohci_port_reset port #0 (twice). No further traffic
in trace. Reverts to adb mouse. No recognition as HID device.
#9.0.4 bus2 kbd then no longer works (due to reset?)

I attempted to replace the 9.0.4 disk based USB drivers with the drivers
from 9.1, which did not work.

#9.1/9.2: mouse and kbd work on both buses. Profiler shows 2 buses with one
device each.

Mac OS X
#10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
mouse. No recognition as HID device.
#10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd
pcap shows normal interrupt operation and recognition as HID device
#10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd
pcap shows normal interrupt operation and recognition as HID device
#10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
mouse. pcap shows no recognition as HID device.
#10.0 in both cases apple system profiler shows 2 usb buses but no devices.


#10.1 bus1 mouse: pcap shows normal interrupt operation and recognition as
HID device, trace shows continuous traffic
#10.1 bus2 kbd: works. pcap shows normal interrupt operation and
recognition as HID device, trace shows continuous traffic
#10.1 bus1 kbd: works. pcap shows normal interrupt operation and
recognition as HID device, trace shows continuous traffic
#10.1 bus2 mouse: pcap shows normal interrupt operation and recognition as
HID device, trace shows continuous traffic
#10.1 Mouse does not move on desktop, but trace shows packets flow.

#10.2/10.3/10.4/10.5 mouse and kbd work on both buses. Profiler shows 2
buses with one device each.

10.0 and 9.0.4 seem to suffer the same issue (mouse not communicating as a
HID device, but 10.1 seems to have another issue.

Attempts to run Mac OS X ioreg show that it fails in that it cannot read
the full registry.
This was already noticed here:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05260.html

-Ioreg from a real G4 running 10.4 and output from the PCI DDK name
registry tool from a real G4 running 9.0.4 and from Qemu running 9.0.4, 9.1
and 9.2 are available here:
https://surfdrive.surf.nl/files/index.php/s/1wcC3GGaagqKVpj/download


Best,
Howard

[-- Attachment #2: Type: text/html, Size: 10011 bytes --]

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> I tested all Mac OS/OSX available to me with mouse and kbd alternately
> connected to usb-bus1 or usb-bus2.
>
> ./qemu-system-ppc \
> -M mac99,usb=off \
> -L pc-bios \
> -boot c \
> -prom-env "auto-boot?=true" \
> -display gtk -monitor stdio \
> -drive file=/home/hsp/Mac-disks/9.0.4.img,format=raw,media=disk \
> -device pci-ohci,id=usb-bus1 \
> -device pci-ohci,id=usb-bus2 \
> -device usb-mouse,bus=usb-bus1.0,pcap=9.0.4_p1_mouse-2usb.pcap \
> -device usb-kbd,bus=usb-bus2.0,pcap=9.0.4_p2_kbd-2usb.pcap \
> -device sungem,netdev=network01 -netdev user,id=network01 \
> -trace "usb_ohci*"
>
> These are the results:
>
> Mac OS:
> #9.0.4 bus1 kbd: works up to usb_ohci_port_reset port #0 in trace, pcap
> shows normal operation and recognition as HID device .
> #9.0.4 bus2 mouse. Reverts to adb mouse. No recognition as HID device.
> #9.0.4 bus1 mouse: usb_ohci_port_reset port #0 (twice). No further traffic
> in trace. Reverts to adb mouse. No recognition as HID device.
> #9.0.4 bus2 kbd then no longer works (due to reset?)
>
> I attempted to replace the 9.0.4 disk based USB drivers with the drivers
> from 9.1, which did not work.
>
> #9.1/9.2: mouse and kbd work on both buses. Profiler shows 2 buses with one
> device each.
>
> Mac OS X
> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> mouse. No recognition as HID device.
> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd
> pcap shows normal interrupt operation and recognition as HID device
> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd
> pcap shows normal interrupt operation and recognition as HID device
> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> mouse. pcap shows no recognition as HID device.
> #10.0 in both cases apple system profiler shows 2 usb buses but no devices.
>
>
> #10.1 bus1 mouse: pcap shows normal interrupt operation and recognition as
> HID device, trace shows continuous traffic
> #10.1 bus2 kbd: works. pcap shows normal interrupt operation and
> recognition as HID device, trace shows continuous traffic
> #10.1 bus1 kbd: works. pcap shows normal interrupt operation and
> recognition as HID device, trace shows continuous traffic
> #10.1 bus2 mouse: pcap shows normal interrupt operation and recognition as
> HID device, trace shows continuous traffic
> #10.1 Mouse does not move on desktop, but trace shows packets flow.
>
> #10.2/10.3/10.4/10.5 mouse and kbd work on both buses. Profiler shows 2
> buses with one device each.

Maybe we need a bit more details from around the point the traces start to 
differ between the versions and about 10-20 lines before it srops and 
10-20 lines after (around) that point with versions that work for 
comparison. It seems the versions that don't work get some error and the 
OHCI device stops or it's something around reset as the suspend is also 
called from there. But we need to locate more where is it in the driver to 
be able to tell what's happening. Maybe also add -trace enable="usb_ohci*" 
-trace enable="usb_port*" and try to correlate what the driver is doing 
by that. The OS X driver sources are available at

https://github.com/apple-oss-distributions/IOHIDFamily

the versions correslonding to OS releases are at

https://opensource.apple.com/releases/

10.1.x had 8.3 and 10.2 had version 33 of this driver but new in 10.2 was

https://github.com/apple-oss-distributions/IOUSBFamily/tree/IOUSBFamily-190.4.1

so it seems there was some bigger change in USB handling between those 
versions. Darwin sources may have more detailed info but I don't know 
where to find those.

> 10.0 and 9.0.4 seem to suffer the same issue (mouse not communicating as a
> HID device, but 10.1 seems to have another issue.
>
> Attempts to run Mac OS X ioreg show that it fails in that it cannot read
> the full registry.
> This was already noticed here:
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05260.html

If this is related to the NVRAM format as speculated in later that thread:

https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05315.html

Then that format is also documented in the sources:

https://github.com/apple-oss-distributions/AppleCore99NVRAM

and there are other emulators that implement it:

https://github.com/dingusdev/dingusppc/blob/master/devices/common/ofnvram.cpp

so this should be easy to fix. Ask Mark to do that in QEMU and OpenBIOS or 
let somebody do it without making a fuss about it. (If we could boot these 
OSes with a firmware ROM from the real machine we could verify if it's a 
problem with NVRAM format or something else. Maybe I should try OS X on 
g3beige but it currently stops in Toolbox ROM before display is up or 
accessing CD so not sure if OS X could boor. If it does not need Toolbox 
just OpenFirmware maybe it could work but I haven't tried yet. What's a 
good version of OS X to run on a real G3 beige?)

> -Ioreg from a real G4 running 10.4 and output from the PCI DDK name
> registry tool from a real G4 running 9.0.4 and from Qemu running 9.0.4, 9.1
> and 9.2 are available here:
> https://surfdrive.surf.nl/files/index.php/s/1wcC3GGaagqKVpj/download

This ioreg output is truncated. Use ioreg -w 0 -l to get a full output.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> Mac OS X
> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> mouse. No recognition as HID device.
> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd
> pcap shows normal interrupt operation and recognition as HID device
> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd
> pcap shows normal interrupt operation and recognition as HID device
> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> mouse. pcap shows no recognition as HID device.
> #10.0 in both cases apple system profiler shows 2 usb buses but no devices.

These are all the logs I get booting a 10.0 install iso with  mac99,via=pmu

>> =============================================================
>> OpenBIOS 1.1 [May 25 2022 20:04]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 256M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,G4
milliseconds isn't unique.
>> switching to new context:
>> call-method slw_update_keymap failed with error ffffffdf
>> call-method slw_update_keymap failed with error ffffffdf
usb_ohci_reset pci-ohci
usb_ohci_stop pci-ohci: USB Suspended
usb_ohci_set_ctl pci-ohci: new state 0x0
usb_ohci_stop pci-ohci: USB Suspended
usb_ohci_port_detach port #0
usb_ohci_port_attach port #0
usb_ohci_port_detach port #1
usb_ohci_port_attach port #1
dbdma_unassigned_flush: use of unassigned channel 0
dbdma_unassigned_flush: use of unassigned channel 0
usb_ohci_mem_write_bad_offset 0x30
usb_ohci_set_ctl pci-ohci: new state 0x80
usb_ohci_start pci-ohci: USB Operational
usb_ohci_hub_power_up powered up all ports
usb_ohci_hub_power_up powered up all ports
usb_ohci_set_ctl pci-ohci: new state 0xc0
usb_ohci_stop pci-ohci: USB Suspended
usb_ohci_hub_power_up powered up all ports
usb_ohci_hub_power_up powered up all ports
usb_ohci_port_reset port #0

It's probably OK until it restarts but the seems to be stopped. Anybody 
wants to have a look? Maybe start with finding what the states mean.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 3295 bytes --]

On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> > Mac OS X
> > #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> > mouse. No recognition as HID device.
> > #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
> kbd
> > pcap shows normal interrupt operation and recognition as HID device
> > #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
> kbd
> > pcap shows normal interrupt operation and recognition as HID device
> > #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> > mouse. pcap shows no recognition as HID device.
> > #10.0 in both cases apple system profiler shows 2 usb buses but no
> devices.
>
> These are all the logs I get booting a 10.0 install iso with  mac99,via=pmu
>
> >> =============================================================
> >> OpenBIOS 1.1 [May 25 2022 20:04]
> >> Configuration device id QEMU version 1 machine id 1
> >> CPUs: 1
> >> Memory: 256M
> >> UUID: 00000000-0000-0000-0000-000000000000
> >> CPU type PowerPC,G4
> milliseconds isn't unique.
> >> switching to new context:
> >> call-method slw_update_keymap failed with error ffffffdf
> >> call-method slw_update_keymap failed with error ffffffdf
> usb_ohci_reset pci-ohci
> usb_ohci_stop pci-ohci: USB Suspended
> usb_ohci_set_ctl pci-ohci: new state 0x0
> usb_ohci_stop pci-ohci: USB Suspended
> usb_ohci_port_detach port #0
> usb_ohci_port_attach port #0
> usb_ohci_port_detach port #1
> usb_ohci_port_attach port #1
> dbdma_unassigned_flush: use of unassigned channel 0
> dbdma_unassigned_flush: use of unassigned channel 0
> usb_ohci_mem_write_bad_offset 0x30
> usb_ohci_set_ctl pci-ohci: new state 0x80
> usb_ohci_start pci-ohci: USB Operational
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_set_ctl pci-ohci: new state 0xc0
> usb_ohci_stop pci-ohci: USB Suspended
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_port_reset port #0
>
> It's probably OK until it restarts but the seems to be stopped. Anybody
> wants to have a look? Maybe start with finding what the states mean.
>
>
I get the same with two usb-ohci controllers (so 6 ports) running Mac OS
9.0.4:

usb_ohci_set_ctl pci-ohci: new state 0x80
usb_ohci_start pci-ohci: USB Operational
usb_ohci_hub_power_up powered up all ports
usb_ohci_hub_power_up powered up all ports
usb_ohci_hub_power_up powered up all ports
usb_ohci_hub_power_up powered up all ports
usb_ohci_hub_power_up powered up all ports
usb_ohci_hub_power_up powered up all ports
usb_ohci_port_reset port #0
usb_ohci_port_reset port #0

So both usb mouse and kbd do not work.

the pcap file for the mouse stalls here:
12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response

However, when I use the usb probe tool from the USB DDK, to probe the buses
I see the host emit a get descriptor

13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE
14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE
15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request
 etc. and this time the mouse is recognised as HID device, the host starts
polling it and mouse and kbd start to work.

Best,
Howard

[-- Attachment #2: Type: text/html, Size: 4097 bytes --]

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> On Thu, 26 Jan 2023, Howard Spoelstra wrote:
>>> Mac OS X
>>> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
>>> mouse. No recognition as HID device.
>>> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
>> kbd
>>> pcap shows normal interrupt operation and recognition as HID device
>>> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
>> kbd
>>> pcap shows normal interrupt operation and recognition as HID device
>>> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
>>> mouse. pcap shows no recognition as HID device.
>>> #10.0 in both cases apple system profiler shows 2 usb buses but no
>> devices.
>>
>> These are all the logs I get booting a 10.0 install iso with  mac99,via=pmu
>>
>>>> =============================================================
>>>> OpenBIOS 1.1 [May 25 2022 20:04]
>>>> Configuration device id QEMU version 1 machine id 1
>>>> CPUs: 1
>>>> Memory: 256M
>>>> UUID: 00000000-0000-0000-0000-000000000000
>>>> CPU type PowerPC,G4
>> milliseconds isn't unique.
>>>> switching to new context:
>>>> call-method slw_update_keymap failed with error ffffffdf
>>>> call-method slw_update_keymap failed with error ffffffdf
>> usb_ohci_reset pci-ohci
>> usb_ohci_stop pci-ohci: USB Suspended
>> usb_ohci_set_ctl pci-ohci: new state 0x0
>> usb_ohci_stop pci-ohci: USB Suspended
>> usb_ohci_port_detach port #0
>> usb_ohci_port_attach port #0
>> usb_ohci_port_detach port #1
>> usb_ohci_port_attach port #1
>> dbdma_unassigned_flush: use of unassigned channel 0
>> dbdma_unassigned_flush: use of unassigned channel 0
>> usb_ohci_mem_write_bad_offset 0x30
>> usb_ohci_set_ctl pci-ohci: new state 0x80
>> usb_ohci_start pci-ohci: USB Operational
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_set_ctl pci-ohci: new state 0xc0
>> usb_ohci_stop pci-ohci: USB Suspended
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_port_reset port #0
>>
>> It's probably OK until it restarts but the seems to be stopped. Anybody
>> wants to have a look? Maybe start with finding what the states mean.
>>
>>
> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS
> 9.0.4:
>
> usb_ohci_set_ctl pci-ohci: new state 0x80
> usb_ohci_start pci-ohci: USB Operational
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_port_reset port #0
> usb_ohci_port_reset port #0
>
> So both usb mouse and kbd do not work.
>
> the pcap file for the mouse stalls here:
> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response

Maybe the driver gets something from the emulated HID device that it 
cannot handle and stops during init? Can you reproduce the same with OS X 
10.0 and try to correlate the events you see in pcap and trace with the 
driver source or find out how to enable and read the messages in the 
driver (unless these are stripped from the binary in Mac OS X but maybe 
there's something in the guest logs; ave you checked those?) In QEMU the 
usb-kbd and mouse are implemented in hw/usb/dev-hid.c but this file does 
not have any debuging or traces. You might try to add some printfs for 
testing.

> However, when I use the usb probe tool from the USB DDK, to probe the buses
> I see the host emit a get descriptor
>
> 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE
> 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE
> 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request
> etc. and this time the mouse is recognised as HID device, the host starts
> polling it and mouse and kbd start to work.

It could be possible that the driver did not get to this point but once 
something else get's past that it recognises the device but I have no idea 
how this works and not even sure which OS you had this result with. Is 
this still 9.0.4? That's hard to debug because we don't know what its 
driver is doing.

Is there a Darwin, OpenDarwin or whatever was that called during the years 
iso that boots on this machine (also on the real one)? That should be 
fully open source and probably have the same drivers as Mac OS X so 
reproducing with that could give some more info or maybe its driver is 
more verbose about errors and has debugging. So you could try to find an 
early Darwin version that's about the same time as early OS X versions or 
look at the IOHIDFamily and try to find what part of it is running when 
you see the logs (as this driver is quite complex it may not be easy).

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Fri, 27 Jan 2023, BALATON Zoltan wrote:
> On Thu, 26 Jan 2023, Howard Spoelstra wrote:
>> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>> On Thu, 26 Jan 2023, Howard Spoelstra wrote:
>>>> Mac OS X
>>>> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
>>>> mouse. No recognition as HID device.
>>>> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
>>> kbd
>>>> pcap shows normal interrupt operation and recognition as HID device
>>>> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
>>> kbd
>>>> pcap shows normal interrupt operation and recognition as HID device
>>>> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
>>>> mouse. pcap shows no recognition as HID device.
>>>> #10.0 in both cases apple system profiler shows 2 usb buses but no
>>> devices.
>>> 
>>> These are all the logs I get booting a 10.0 install iso with 
>>> mac99,via=pmu
>>> 
>>>>> =============================================================
>>>>> OpenBIOS 1.1 [May 25 2022 20:04]
>>>>> Configuration device id QEMU version 1 machine id 1
>>>>> CPUs: 1
>>>>> Memory: 256M
>>>>> UUID: 00000000-0000-0000-0000-000000000000
>>>>> CPU type PowerPC,G4
>>> milliseconds isn't unique.
>>>>> switching to new context:
>>>>> call-method slw_update_keymap failed with error ffffffdf
>>>>> call-method slw_update_keymap failed with error ffffffdf
>>> usb_ohci_reset pci-ohci
>>> usb_ohci_stop pci-ohci: USB Suspended
>>> usb_ohci_set_ctl pci-ohci: new state 0x0
>>> usb_ohci_stop pci-ohci: USB Suspended
>>> usb_ohci_port_detach port #0
>>> usb_ohci_port_attach port #0
>>> usb_ohci_port_detach port #1
>>> usb_ohci_port_attach port #1
>>> dbdma_unassigned_flush: use of unassigned channel 0
>>> dbdma_unassigned_flush: use of unassigned channel 0
>>> usb_ohci_mem_write_bad_offset 0x30
>>> usb_ohci_set_ctl pci-ohci: new state 0x80
>>> usb_ohci_start pci-ohci: USB Operational
>>> usb_ohci_hub_power_up powered up all ports
>>> usb_ohci_hub_power_up powered up all ports
>>> usb_ohci_set_ctl pci-ohci: new state 0xc0
>>> usb_ohci_stop pci-ohci: USB Suspended
>>> usb_ohci_hub_power_up powered up all ports
>>> usb_ohci_hub_power_up powered up all ports
>>> usb_ohci_port_reset port #0
>>> 
>>> It's probably OK until it restarts but the seems to be stopped. Anybody
>>> wants to have a look? Maybe start with finding what the states mean.
>>> 
>>> 
>> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS
>> 9.0.4:
>> 
>> usb_ohci_set_ctl pci-ohci: new state 0x80
>> usb_ohci_start pci-ohci: USB Operational
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_hub_power_up powered up all ports
>> usb_ohci_port_reset port #0
>> usb_ohci_port_reset port #0
>> 
>> So both usb mouse and kbd do not work.
>> 
>> the pcap file for the mouse stalls here:
>> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response
>
> Maybe the driver gets something from the emulated HID device that it cannot 
> handle and stops during init? Can you reproduce the same with OS X 10.0 and 
> try to correlate the events you see in pcap and trace with the driver source 
> or find out how to enable and read the messages in the driver (unless these 
> are stripped from the binary in Mac OS X but maybe there's something in the 
> guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are 
> implemented in hw/usb/dev-hid.c but this file does not have any debuging or 
> traces. You might try to add some printfs for testing.
>
>> However, when I use the usb probe tool from the USB DDK, to probe the buses
>> I see the host emit a get descriptor
>> 
>> 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE
>> 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE
>> 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request
>> etc. and this time the mouse is recognised as HID device, the host starts
>> polling it and mouse and kbd start to work.
>
> It could be possible that the driver did not get to this point but once 
> something else get's past that it recognises the device but I have no idea 
> how this works and not even sure which OS you had this result with. Is this 
> still 9.0.4? That's hard to debug because we don't know what its driver is 
> doing.
>
> Is there a Darwin, OpenDarwin or whatever was that called during the years 
> iso that boots on this machine (also on the real one)? That should be fully 
> open source and probably have the same drivers as Mac OS X so reproducing 
> with that could give some more info or maybe its driver is more verbose about 
> errors and has debugging. So you could try to find an early Darwin version 
> that's about the same time as early OS X versions or look at the IOHIDFamily 
> and try to find what part of it is running when you see the logs (as this 
> driver is quite complex it may not be easy).

The oldest Darwin CD I could find is 6.2 which boots and works so it's not 
old enough for us.

The simplest driver is in the oldest 10.0 version so maybe we should try 
to look at that:

https://github.com/apple-oss-distributions/IOHIDFamily/tree/IOHIDFamily-6

and the low level part is in the xnu kernel:

https://github.com/apple-oss-distributions/xnu/tree/xnu-123.5/iokit/Families/IOHIDSystem

I don't quite know how it works and where it starts running but a large 
part of it looks like it handles key mapping. While booting I see an error 
from OpenBIOS saying:

>> call-method slw_update_keymap failed with error ffffffdf

Could this be related to the problem? What is this error about? This 
PearPC bug has some info on where it may come from:

https://github.com/sebastianbiallas/pearpc/issues/4

but I don't know if any of this is relevant.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 6470 bytes --]

On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Fri, 27 Jan 2023, BALATON Zoltan wrote:
> > On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> >> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton@eik.bme.hu>
> wrote:
> >>> On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> >>>> Mac OS X
> >>>> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to
> adb
> >>>> mouse. No recognition as HID device.
> >>>> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that
> point
> >>> kbd
> >>>> pcap shows normal interrupt operation and recognition as HID device
> >>>> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that
> point
> >>> kbd
> >>>> pcap shows normal interrupt operation and recognition as HID device
> >>>> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to
> adb
> >>>> mouse. pcap shows no recognition as HID device.
> >>>> #10.0 in both cases apple system profiler shows 2 usb buses but no
> >>> devices.
> >>>
> >>> These are all the logs I get booting a 10.0 install iso with
> >>> mac99,via=pmu
> >>>
> >>>>> =============================================================
> >>>>> OpenBIOS 1.1 [May 25 2022 20:04]
> >>>>> Configuration device id QEMU version 1 machine id 1
> >>>>> CPUs: 1
> >>>>> Memory: 256M
> >>>>> UUID: 00000000-0000-0000-0000-000000000000
> >>>>> CPU type PowerPC,G4
> >>> milliseconds isn't unique.
> >>>>> switching to new context:
> >>>>> call-method slw_update_keymap failed with error ffffffdf
> >>>>> call-method slw_update_keymap failed with error ffffffdf
> >>> usb_ohci_reset pci-ohci
> >>> usb_ohci_stop pci-ohci: USB Suspended
> >>> usb_ohci_set_ctl pci-ohci: new state 0x0
> >>> usb_ohci_stop pci-ohci: USB Suspended
> >>> usb_ohci_port_detach port #0
> >>> usb_ohci_port_attach port #0
> >>> usb_ohci_port_detach port #1
> >>> usb_ohci_port_attach port #1
> >>> dbdma_unassigned_flush: use of unassigned channel 0
> >>> dbdma_unassigned_flush: use of unassigned channel 0
> >>> usb_ohci_mem_write_bad_offset 0x30
> >>> usb_ohci_set_ctl pci-ohci: new state 0x80
> >>> usb_ohci_start pci-ohci: USB Operational
> >>> usb_ohci_hub_power_up powered up all ports
> >>> usb_ohci_hub_power_up powered up all ports
> >>> usb_ohci_set_ctl pci-ohci: new state 0xc0
> >>> usb_ohci_stop pci-ohci: USB Suspended
> >>> usb_ohci_hub_power_up powered up all ports
> >>> usb_ohci_hub_power_up powered up all ports
> >>> usb_ohci_port_reset port #0
> >>>
> >>> It's probably OK until it restarts but the seems to be stopped. Anybody
> >>> wants to have a look? Maybe start with finding what the states mean.
> >>>
> >>>
> >> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS
> >> 9.0.4:
> >>
> >> usb_ohci_set_ctl pci-ohci: new state 0x80
> >> usb_ohci_start pci-ohci: USB Operational
> >> usb_ohci_hub_power_up powered up all ports
> >> usb_ohci_hub_power_up powered up all ports
> >> usb_ohci_hub_power_up powered up all ports
> >> usb_ohci_hub_power_up powered up all ports
> >> usb_ohci_hub_power_up powered up all ports
> >> usb_ohci_hub_power_up powered up all ports
> >> usb_ohci_port_reset port #0
> >> usb_ohci_port_reset port #0
> >>
> >> So both usb mouse and kbd do not work.
> >>
> >> the pcap file for the mouse stalls here:
> >> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response
> >
> > Maybe the driver gets something from the emulated HID device that it
> cannot
> > handle and stops during init? Can you reproduce the same with OS X 10.0
> and
> > try to correlate the events you see in pcap and trace with the driver
> source
> > or find out how to enable and read the messages in the driver (unless
> these
> > are stripped from the binary in Mac OS X but maybe there's something in
> the
> > guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are
> > implemented in hw/usb/dev-hid.c but this file does not have any debuging
> or
> > traces. You might try to add some printfs for testing.
> >
> >> However, when I use the usb probe tool from the USB DDK, to probe the
> buses
> >> I see the host emit a get descriptor
> >>
> >> 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE
> >> 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE
> >> 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request
> >> etc. and this time the mouse is recognised as HID device, the host
> starts
> >> polling it and mouse and kbd start to work.
> >
> > It could be possible that the driver did not get to this point but once
> > something else get's past that it recognises the device but I have no
> idea
> > how this works and not even sure which OS you had this result with. Is
> this
> > still 9.0.4? That's hard to debug because we don't know what its driver
> is
> > doing.
> >
> > Is there a Darwin, OpenDarwin or whatever was that called during the
> years
> > iso that boots on this machine (also on the real one)? That should be
> fully
> > open source and probably have the same drivers as Mac OS X so
> reproducing
> > with that could give some more info or maybe its driver is more verbose
> about
> > errors and has debugging. So you could try to find an early Darwin
> version
> > that's about the same time as early OS X versions or look at the
> IOHIDFamily
> > and try to find what part of it is running when you see the logs (as
> this
> > driver is quite complex it may not be easy).
>
> The oldest Darwin CD I could find is 6.2 which boots and works so it's not
> old enough for us.
>
> The simplest driver is in the oldest 10.0 version so maybe we should try
> to look at that:
>
> https://github.com/apple-oss-distributions/IOHIDFamily/tree/IOHIDFamily-6
>
> and the low level part is in the xnu kernel:
>
>
> https://github.com/apple-oss-distributions/xnu/tree/xnu-123.5/iokit/Families/IOHIDSystem
>
> I don't quite know how it works and where it starts running but a large
> part of it looks like it handles key mapping. While booting I see an error
> from OpenBIOS saying:
>
> >> call-method slw_update_keymap failed with error ffffffdf
>
> Could this be related to the problem? What is this error about? This
> PearPC bug has some info on where it may come from:
>
>
This seem to come from here:
https://web.archive.org/web/20150922180615/http://www.opensource.apple.com/source/BootX/BootX-45/bootx.tproj/ci.subproj/sl_words.c


> https://github.com/sebastianbiallas/pearpc/issues/4
>
> but I don't know if any of this is relevant.
>
> Regards,
> BALATON Zoltan
>

[-- Attachment #2: Type: text/html, Size: 8780 bytes --]

Error detecting linker while compiling qemu-system-ppc on macOS

[Howard Spoelstra]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

Hi all,

I'm getting a error while compiling on macOS (Intel). It seems linker
detection is passed an unknown argument "--version", whereas "-v" works OK?
See log below.

Thanks for looking into this,
Howard

Build started at 2023-11-06T07:29:19.181487
Main binary: /Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11
Build Options: -Db_pie=false -Ddocs=disabled -Dplugins=true '--native-file
config-meson.cross'
Python system: Darwin
The Meson build system
Version: 0.63.3
Source dir: /Users/hsp/src/qemu-ppc
Build dir: /Users/hsp/src/qemu-ppc/build
Build type: native build
Project name: qemu
Project version: 8.1.50
-----
Detecting compiler via: cc -m64 -mcx16 --version
compiler returned <Popen: returncode: 0 args: ['cc', '-m64', '-mcx16',
'--version']>
compiler stdout:
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

compiler stderr:

Running command: cc -m64 -mcx16 -E -dM -
-----
Detecting linker via: cc -m64 -mcx16 -Wl,--version
linker returned <Popen: returncode: 1 args: ['cc', '-m64', '-mcx16',
'-Wl,--version']>
linker stdout:

linker stderr:
ld: unknown options: --version
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

-----
Detecting Apple linker via: cc -m64 -mcx16 -Wl,-v
linker stdout:

linker stderr:
@(#)PROGRAM:ld  PROJECT:dyld-1015.7
BUILD 18:48:43 Aug 22 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386
x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k
armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is
29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
Library search paths:
/usr/local/lib
Framework search paths:
ld: Undefined symbols:
  _main, referenced from:
      <initial-undefines>
clang: error: linker command failed with exit code 1 (use -v to see
invocation)


../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -m64
-mcx16 -Wl,--version`
stdout:
stderr: ld: unknown options: --version
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

[-- Attachment #2: Type: text/html, Size: 2654 bytes --]

Re: Error detecting linker while compiling qemu-system-ppc on macOS

[BALATON Zoltan]

Hello,

On Mon, 6 Nov 2023, Howard Spoelstra wrote:
> Hi all,
>
> I'm getting a error while compiling on macOS (Intel). It seems linker
> detection is passed an unknown argument "--version", whereas "-v" works OK?
> See log below.

See also 
https://lists.nongnu.org/archive/html/qemu-devel/2023-10/msg10375.html
and the tickets listed in there. It should work with meson 1.2.x according 
to Rene's ticket to Meson and you can install that from homebrew but it 
seems it's not picked up. Why is it using 
/Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11 ? How many pythons do 
you8 have on macOS? What does which python tell you and does it work 
better when you add --python=/path/to/python/that/homebrew/meson/uses ?

Regards,
BALATON Zoltan

> Thanks for looking into this,
> Howard
>
> Build started at 2023-11-06T07:29:19.181487
> Main binary: /Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11
> Build Options: -Db_pie=false -Ddocs=disabled -Dplugins=true '--native-file
> config-meson.cross'
> Python system: Darwin
> The Meson build system
> Version: 0.63.3
> Source dir: /Users/hsp/src/qemu-ppc
> Build dir: /Users/hsp/src/qemu-ppc/build
> Build type: native build
> Project name: qemu
> Project version: 8.1.50
> -----
> Detecting compiler via: cc -m64 -mcx16 --version
> compiler returned <Popen: returncode: 0 args: ['cc', '-m64', '-mcx16',
> '--version']>
> compiler stdout:
> Apple clang version 15.0.0 (clang-1500.0.40.1)
> Target: x86_64-apple-darwin22.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>
> compiler stderr:
>
> Running command: cc -m64 -mcx16 -E -dM -
> -----
> Detecting linker via: cc -m64 -mcx16 -Wl,--version
> linker returned <Popen: returncode: 1 args: ['cc', '-m64', '-mcx16',
> '-Wl,--version']>
> linker stdout:
>
> linker stderr:
> ld: unknown options: --version
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> -----
> Detecting Apple linker via: cc -m64 -mcx16 -Wl,-v
> linker stdout:
>
> linker stderr:
> @(#)PROGRAM:ld  PROJECT:dyld-1015.7
> BUILD 18:48:43 Aug 22 2023
> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386
> x86_64 x86_64h armv6m armv7k armv7m armv7em
> will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k
> armv7m armv7em
> LTO support using: LLVM version 15.0.0 (static support for 29, runtime is
> 29)
> TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
> Library search paths:
> /usr/local/lib
> Framework search paths:
> ld: Undefined symbols:
>  _main, referenced from:
>      <initial-undefines>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> ../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -m64
> -mcx16 -Wl,--version`
> stdout:
> stderr: ld: unknown options: --version
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
> 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:
>>>> - 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.

As a maintainer you could help reducing the size of the series and patches 
under review by queuing the patches that are already reviewed then 
hopefully there are only a few left to discuss. One reason for changing 
the series was to omit patches you've dismissed right away and move the 
ones reviewed or those you were less resistant about to the front so you 
could easily merge them and reduce the size of the remaining series that 
I'll have to roll and respin later. So queueing those you're already OK 
with could help making this clearer.

>>>> 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.

This would create a lot of duplicated code and increase the nunber of 
machines to maintain so I don't think this is a good idea at this point. I 
also don't want to change any of these machines now. The mac99.via=pmu is 
sufficiently close to PowerMac3,1 already. All I want is to have separate 
machine names for the machines we emulate. This is to

1. resolve the confusion this causes to usesrs
2. allow deprecating old ways of specifying these so we can eventually get 
rid of those
3. and this will also allow later to split the implementation if we need 
to or add new machines from scratch that will fit in the new naming

So what you propose is not needed now and don't see why you think it would 
be needed just to resolve the names now.

>>> 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?

I don't know. If we were saying the same why are you not happy with the 
patch? I probably don't get what your concern is. To me it looks like you 
just resist any change without a clear reason and try to come up with 
excuses why not to merge these patches. My point was that this patch 
should not break any command lines for anybody, it will just issue 
warnings for the via option and ppc64 mac99 telling users to use new 
-machine options instead. They can keep using ppc mac99 without a warning 
and it can be either kept as it is for backwards compatibility or 
deprecated later once the other machines are better. If your concern was 
that it might break something for somebody then it's not likely as this 
does not change the machines' implementation just adds explicit names for 
those which are currently only accessible by options and defaults.

Spliting the ppc and ppc64 mac99 as you say would increase the chance of 
it breaking in the future because you'll then need to make every change in 
two places and if you forget it's easier to break. So this patch leaves 
the implementation shared but adds separate names so they can be split as 
at a later point without addecting users but no need to do that change 
now. Just separating the name is enough and it has less chance to break 
anything.

>>> 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.
>
> 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?

No I don't want it to diverge just to be available as a machine option 
instead of a cryptic option that nobody can find out without being told. 
If you now do qemu-system-ppc64 -machine help you'll see:

$ qemu-system-ppc64 -machine help
Supported machines are:
40p                  IBM RS/6000 7020 (40p)
bamboo               bamboo
g3beige              Heathrow based PowerMAC
mac99                Mac99 based PowerMAC
mpc8544ds            mpc8544ds
none                 empty machine
pegasos2             Genesi/bPlan Pegasos II
powernv10            IBM PowerNV (Non-Virtualized) POWER10
powernv8             IBM PowerNV (Non-Virtualized) POWER8
[...]

How do you know how to emulate a G5 Mac and a G4 Mac? You don't without 
reading docs (which nobody does) or asking (which nobody does either). 
Instead they try mac99 and find it does not work and abandon it. After 
this patch you'll get:

$ qemu-system-ppc64 -machine help
Supported machines are:
40p                  IBM RS/6000 7020 (40p)
bamboo               bamboo
g3beige              Heathrow based PowerMAC
mac99                Mac99 based PowerMAC
mpc8544ds            mpc8544ds
none                 empty machine
pegasos2             Genesi/bPlan Pegasos II
powerbook3_2         Apple PowerBook G4 Titanium (Mercury)
powermac3_1          Apple Power Mac G4 AGP (Sawtooth)
powermac7_3          Apple Power Mac G5 (Niagara)
powernv10            IBM PowerNV (Non-Virtualized) POWER10
powernv8             IBM PowerNV (Non-Virtualized) POWER8

and specifying the -machine option will give you the right machine right 
away. I really don't know what is so hard to get about this that I have to 
ecplain it all over again for 3 months now since I've first submitted 
these.

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Thu, 12 Jan 2023, Howard Spoelstra wrote:
> 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.

True it never had ADB and makes not much sense to run it with a G3 
(although you probably could, just nobody wanted to; but the other way 
around, i.e. according to https://en.wikipedia.org/wiki/Power_Mac_G4 the 
first PCI only G4 PowerMac1,2 had a motherboard from a G3 Mac just with a 
G4 CPU). But the G4 AGP could have a 900 MHz or faster CPU via a CPU 
upgrade:

https://lowendmac.com/newsrev/07/0330.html#b
https://lowendmac.com/newsrev/mnr07/1029.html
https://lowendmac.com/ppc/power-mac-g4-upgrade-guide.html

These links are from this page:

https://lowendmac.com/1999/power-mac-g4-sawtooth/

also may be of interest:

https://lowendmac.com/1998/beige-power-mac-g3-1998/
https://lowendmac.com/1997/beige-power-mac-g3-1997/

Regards,
BALATON Zoltan

Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]



> On Jan 4, 2023, at 2:59 PM, BALATON Zoltan <balaton@eik.bme.hu> 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>
> ---
> hw/ppc/mac_newworld.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index f07c37328b..adf185bd3a 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
>         if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
>             warn_report("mac99 with G5 CPU is deprecated, "
>                         "use powermac7_3 instead");
> +        } else {
> +            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
> +                warn_report("mac99,via=pmu is deprecated, "
> +                            "use powermac3_1 instead");

so use ‘-m mac99,via=powermac3_1’ or ‘-m powermac3_1’ or ‘-m mac99,powerpmac3_1’

I have no clue which one I’m supposed to use. It would be better to tell the user
which of these three possibilities they should really use. From the other patches
in the series, I’m guessing it’s the middle one, but even after looking at the code, I’m
unsure.

> +            }
> +            if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
> +                warn_report("mac99,via=pmu-adb is deprecated, "
> +                            "use powerbook3_2 instead");

Same basic comment here.

I’m thinking adding '-m’ or ‘machine type’ before powerbook… in both of these would
resolve it..

Warner

> +            }
>         }
>     }
>     /* allocate RAM */
> --
> 2.30.6
> 
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

[PATCH v7 7/7] mac_newworld: Document deprecation

[BALATON Zoltan]

Also update PowerMac family docs with some more recent info.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
 docs/about/deprecated.rst    |  7 +++++++
 docs/system/ppc/powermac.rst | 12 ++++++++----
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 93affe3669..07661af7fe 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -248,6 +248,13 @@ These old machine types are quite neglected nowadays and thus might have
 various pitfalls with regards to live migration. Use a newer machine type
 instead.
 
+``mac99`` variants other than the default qemu-system-ppc version (since 7.2)
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The ``mac99`` machine emulates different hardware depending on using
+qemu-system-ppc64 or ``via`` property. To avoid confusion new machine
+types has been added for these variants which are now preferred over
+``mac99``.
 
 Backend options
 ---------------
diff --git a/docs/system/ppc/powermac.rst b/docs/system/ppc/powermac.rst
index 04334ba210..d4a47a6881 100644
--- a/docs/system/ppc/powermac.rst
+++ b/docs/system/ppc/powermac.rst
@@ -4,8 +4,12 @@ PowerMac family boards (``g3beige``, ``mac99``)
 Use the executable ``qemu-system-ppc`` to simulate a complete PowerMac
 PowerPC system.
 
-- ``g3beige``              Heathrow based PowerMAC
-- ``mac99``                Mac99 based PowerMAC
+- ``g3beige``           Heathrow based old world Power Macintosh G3
+- ``mac99``             Core99 based generic PowerMac
+- ``powermac3_1``       Power Mac G4 AGP (Sawtooth)
+- ``powerbook3_2``      PowerBook G4 Titanium (Mercury)
+- ``powermac7_3``       Power Mac G5 (Niagara) (only in ``qemu-system-ppc64``)
+
 
 Supported devices
 -----------------
@@ -15,9 +19,9 @@ QEMU emulates the following PowerMac peripherals:
  *  UniNorth or Grackle PCI Bridge
  *  PCI VGA compatible card with VESA Bochs Extensions
  *  2 PMAC IDE interfaces with hard disk and CD-ROM support
- *  NE2000 PCI adapters
+ *  Sungem PCI network adapter
  *  Non Volatile RAM
- *  VIA-CUDA with ADB keyboard and mouse.
+ *  VIA-CUDA or VIA-PMU99 with or without ADB or USB keyboard and mouse.
 
 
 Missing devices
-- 
2.30.6

Re: [PATCH v7 7/7] mac_newworld: Document deprecation

[Philippe Mathieu-Daudé]

On 4/1/23 22:59, BALATON Zoltan wrote:
> Also update PowerMac family docs with some more recent info.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>   docs/about/deprecated.rst    |  7 +++++++
>   docs/system/ppc/powermac.rst | 12 ++++++++----
>   2 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 93affe3669..07661af7fe 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -248,6 +248,13 @@ These old machine types are quite neglected nowadays and thus might have
>   various pitfalls with regards to live migration. Use a newer machine type
>   instead.
>   
> +``mac99`` variants other than the default qemu-system-ppc version (since 7.2)
> +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The ``mac99`` machine emulates different hardware depending on using
> +qemu-system-ppc64 or ``via`` property. To avoid confusion new machine
> +types has been added for these variants which are now preferred over
> +``mac99``.

^ this part is OK,

but below is part of patch 4/7 "Add different mac99 machine types".

> diff --git a/docs/system/ppc/powermac.rst b/docs/system/ppc/powermac.rst
> index 04334ba210..d4a47a6881 100644
> --- a/docs/system/ppc/powermac.rst
> +++ b/docs/system/ppc/powermac.rst
> @@ -4,8 +4,12 @@ PowerMac family boards (``g3beige``, ``mac99``)
>   Use the executable ``qemu-system-ppc`` to simulate a complete PowerMac
>   PowerPC system.
>   
> -- ``g3beige``              Heathrow based PowerMAC
> -- ``mac99``                Mac99 based PowerMAC
> +- ``g3beige``           Heathrow based old world Power Macintosh G3
> +- ``mac99``             Core99 based generic PowerMac
> +- ``powermac3_1``       Power Mac G4 AGP (Sawtooth)
> +- ``powerbook3_2``      PowerBook G4 Titanium (Mercury)
> +- ``powermac7_3``       Power Mac G5 (Niagara) (only in ``qemu-system-ppc64``)
> +
>   
>   Supported devices
>   -----------------
> @@ -15,9 +19,9 @@ QEMU emulates the following PowerMac peripherals:
>    *  UniNorth or Grackle PCI Bridge
>    *  PCI VGA compatible card with VESA Bochs Extensions
>    *  2 PMAC IDE interfaces with hard disk and CD-ROM support
> - *  NE2000 PCI adapters
> + *  Sungem PCI network adapter
>    *  Non Volatile RAM
> - *  VIA-CUDA with ADB keyboard and mouse.
> + *  VIA-CUDA or VIA-PMU99 with or without ADB or USB keyboard and mouse.
>   
>   
>   Missing devices

Re: [PATCH v7 7/7] mac_newworld: Document deprecation

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]

On Thu, 5 Jan 2023, Philippe Mathieu-Daudé wrote:
> On 4/1/23 22:59, BALATON Zoltan wrote:
>> Also update PowerMac family docs with some more recent info.
>> 
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>>   docs/about/deprecated.rst    |  7 +++++++
>>   docs/system/ppc/powermac.rst | 12 ++++++++----
>>   2 files changed, 15 insertions(+), 4 deletions(-)
>> 
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 93affe3669..07661af7fe 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -248,6 +248,13 @@ These old machine types are quite neglected nowadays 
>> and thus might have
>>   various pitfalls with regards to live migration. Use a newer machine type
>>   instead.
>>   +``mac99`` variants other than the default qemu-system-ppc version (since 
>> 7.2)
>> +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>> +
>> +The ``mac99`` machine emulates different hardware depending on using
>> +qemu-system-ppc64 or ``via`` property. To avoid confusion new machine
>> +types has been added for these variants which are now preferred over
>> +``mac99``.
>
> ^ this part is OK,
>
> but below is part of patch 4/7 "Add different mac99 machine types".

Not really, as that patch does not add these. It's already the current 
state which this patch just documents so this is just updating docs. If 
anything then the above part about deprecating mac99 may be squashed with 
patch 5 and 6 to make a single deprecation patch but I'll see what the 
maintainer prefers because whatever I come up with is usually not what he 
likes so to avoid wasted effort I'd rather wait for clear instructions 
before making more changes.

Regards,
BALATON Zoltan

>> diff --git a/docs/system/ppc/powermac.rst b/docs/system/ppc/powermac.rst
>> index 04334ba210..d4a47a6881 100644
>> --- a/docs/system/ppc/powermac.rst
>> +++ b/docs/system/ppc/powermac.rst
>> @@ -4,8 +4,12 @@ PowerMac family boards (``g3beige``, ``mac99``)
>>   Use the executable ``qemu-system-ppc`` to simulate a complete PowerMac
>>   PowerPC system.
>>   -- ``g3beige``              Heathrow based PowerMAC
>> -- ``mac99``                Mac99 based PowerMAC
>> +- ``g3beige``           Heathrow based old world Power Macintosh G3
>> +- ``mac99``             Core99 based generic PowerMac
>> +- ``powermac3_1``       Power Mac G4 AGP (Sawtooth)
>> +- ``powerbook3_2``      PowerBook G4 Titanium (Mercury)
>> +- ``powermac7_3``       Power Mac G5 (Niagara) (only in 
>> ``qemu-system-ppc64``)
>> +
>>     Supported devices
>>   -----------------
>> @@ -15,9 +19,9 @@ QEMU emulates the following PowerMac peripherals:
>>    *  UniNorth or Grackle PCI Bridge
>>    *  PCI VGA compatible card with VESA Bochs Extensions
>>    *  2 PMAC IDE interfaces with hard disk and CD-ROM support
>> - *  NE2000 PCI adapters
>> + *  Sungem PCI network adapter
>>    *  Non Volatile RAM
>> - *  VIA-CUDA with ADB keyboard and mouse.
>> + *  VIA-CUDA or VIA-PMU99 with or without ADB or USB keyboard and mouse.
>>       Missing devices
>
>
>

Re: [PATCH v7 0/7] Misc ppc/mac machines clean up

[Mark Cave-Ayland]

On 04/01/2023 21:59, BALATON Zoltan wrote:

> This is the remainder of the series that were postponed to after the
> freeze the last time I've tried to submit them with some new patches
> I did meanwhile.
> 
> BALATON Zoltan (7):
>    input/adb: Only include header where needed
>    mac_{old,new}world: Use local variable instead of qdev_get_machine()
>    mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
>    mac_newworld: Add machine types for different mac99 configs
>    mac_newworld: Deprecate mac99 with G5 CPU
>    mac_newworld: Deprecate mac99 "via" option
>    mac_newworld: Document deprecation
> 
>   docs/about/deprecated.rst    |   7 ++
>   docs/system/ppc/powermac.rst |  12 ++--
>   hw/misc/macio/cuda.c         |   2 -
>   hw/misc/macio/pmu.c          |   3 -
>   hw/misc/mos6522.c            |   1 -
>   hw/ppc/mac_newworld.c        | 130 +++++++++++++++++++++++++++++++----
>   hw/ppc/mac_oldworld.c        |  21 ++----
>   include/hw/misc/mac_via.h    |   1 +
>   include/hw/misc/macio/cuda.h |   1 +
>   include/hw/misc/macio/pmu.h  |   1 +
>   include/hw/misc/mos6522.h    |   3 +-
>   11 files changed, 142 insertions(+), 40 deletions(-)

I've applied patches 1 and 2 to my qemu-macppc branch. Patch 3 isn't the right 
solution to the problem, and the discussion as to how the New World machines should 
be organised in future for patches 4 to 7 still hasn't been clarified.


ATB,

Mark.

Re: [PATCH v7 0/7] Misc ppc/mac machines clean up

[BALATON Zoltan]

On Wed, 1 Feb 2023, Mark Cave-Ayland wrote:
> On 04/01/2023 21:59, BALATON Zoltan wrote:
>> This is the remainder of the series that were postponed to after the
>> freeze the last time I've tried to submit them with some new patches
>> I did meanwhile.
>> 
>> BALATON Zoltan (7):
>>    input/adb: Only include header where needed
>>    mac_{old,new}world: Use local variable instead of qdev_get_machine()
>>    mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
>>    mac_newworld: Add machine types for different mac99 configs
>>    mac_newworld: Deprecate mac99 with G5 CPU
>>    mac_newworld: Deprecate mac99 "via" option
>>    mac_newworld: Document deprecation
>>
>>   docs/about/deprecated.rst    |   7 ++
>>   docs/system/ppc/powermac.rst |  12 ++--
>>   hw/misc/macio/cuda.c         |   2 -
>>   hw/misc/macio/pmu.c          |   3 -
>>   hw/misc/mos6522.c            |   1 -
>>   hw/ppc/mac_newworld.c        | 130 +++++++++++++++++++++++++++++++----
>>   hw/ppc/mac_oldworld.c        |  21 ++----
>>   include/hw/misc/mac_via.h    |   1 +
>>   include/hw/misc/macio/cuda.h |   1 +
>>   include/hw/misc/macio/pmu.h  |   1 +
>>   include/hw/misc/mos6522.h    |   3 +-
>>   11 files changed, 142 insertions(+), 40 deletions(-)
>
> I've applied patches 1 and 2 to my qemu-macppc branch. Patch 3 isn't the 
> right solution to the problem, and the discussion as to how the New World 
> machines should be organised in future for patches 4 to 7 still hasn't been 
> clarified.

Thanks, let's come back to patch 3 in the other thread. As for 4-7 the 
discussion seems to have ended and the result was that nobody really cares 
besides you and me. So make a suggestion for names instead of the machine 
id based ones I came up with and I'll change it to use those names. 
Whatever we call these is still better than what we have currently so as 
long as I can get PowerMac3,1 and PowerMac7,2 with a simple -machine 
option without getting them confused in qemu-system-ppc64 I'd go for that.

Regards,
BALATON Zoltan

Re: [PATCH v7 0/7] Misc ppc/mac machines clean up

[BALATON Zoltan]

On Thu, 2 Feb 2023, BALATON Zoltan wrote:
> On Wed, 1 Feb 2023, Mark Cave-Ayland wrote:
>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>> This is the remainder of the series that were postponed to after the
>>> freeze the last time I've tried to submit them with some new patches
>>> I did meanwhile.
>>> 
>>> BALATON Zoltan (7):
>>>    input/adb: Only include header where needed
>>>    mac_{old,new}world: Use local variable instead of qdev_get_machine()
>>>    mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
>>>    mac_newworld: Add machine types for different mac99 configs
>>>    mac_newworld: Deprecate mac99 with G5 CPU
>>>    mac_newworld: Deprecate mac99 "via" option
>>>    mac_newworld: Document deprecation
>>>
>>>   docs/about/deprecated.rst    |   7 ++
>>>   docs/system/ppc/powermac.rst |  12 ++--
>>>   hw/misc/macio/cuda.c         |   2 -
>>>   hw/misc/macio/pmu.c          |   3 -
>>>   hw/misc/mos6522.c            |   1 -
>>>   hw/ppc/mac_newworld.c        | 130 +++++++++++++++++++++++++++++++----
>>>   hw/ppc/mac_oldworld.c        |  21 ++----
>>>   include/hw/misc/mac_via.h    |   1 +
>>>   include/hw/misc/macio/cuda.h |   1 +
>>>   include/hw/misc/macio/pmu.h  |   1 +
>>>   include/hw/misc/mos6522.h    |   3 +-
>>>   11 files changed, 142 insertions(+), 40 deletions(-)
>> 
>> I've applied patches 1 and 2 to my qemu-macppc branch. Patch 3 isn't the 
>> right solution to the problem, and the discussion as to how the New World 
>> machines should be organised in future for patches 4 to 7 still hasn't been 
>> clarified.
>
> Thanks, let's come back to patch 3 in the other thread. As for 4-7 the 
> discussion seems to have ended and the result was that nobody really cares 
> besides you and me. So make a suggestion for names instead of the machine id 
> based ones I came up with and I'll change it to use those names. Whatever we 
> call these is still better than what we have currently so as long as I can 
> get PowerMac3,1 and PowerMac7,2 with a simple -machine option without getting 
> them confused in qemu-system-ppc64 I'd go for that.

Thank you for taking care of these, now only the last patches are not yet 
merged. We can postpone the NDRV patch for later but I'd appreciate if you 
could make an alternative fix in OpenBIOS. I'd still want to resolve the 
mac99 machine though and add new machine names and start deprecation now. 
I'm waiting for your suggestion on names for these machines and preferred 
partitioning of the changes in patches so I can change and resubmit these. 
I'd like this to not miss the freeze which may seem far ahead but at the 
speed these are reviewed and merged I wanted to get over it as soon as 
possible. (Othersise this would be the second time these miss a freeze.)

Regards,
BALATON Zoltan