Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> writes: > On 03/05/2022 15:06, Fabiano Rosas wrote: > >> Murilo Opsfelder Araújo <muri...@linux.ibm.com> writes: >> >>> $ cat > configs/devices/rh-virtio.mak <<"EOF" >>> CONFIG_VIRTIO=y >>> CONFIG_VIRTIO_BALLOON=y >>> CONFIG_VIRTIO_BLK=y >>> CONFIG_VIRTIO_GPU=y >>> CONFIG_VIRTIO_INPUT=y >>> CONFIG_VIRTIO_INPUT_HOST=y >>> CONFIG_VIRTIO_NET=y >>> CONFIG_VIRTIO_RNG=y >>> CONFIG_VIRTIO_SCSI=y >>> CONFIG_VIRTIO_SERIAL=y >>> EOF >>> >>> $ cat > configs/devices/ppc64-softmmu/ppc64-rh-devices.mak <<"EOF" >>> include ../rh-virtio.mak >>> CONFIG_DIMM=y >>> CONFIG_MEM_DEVICE=y >>> CONFIG_NVDIMM=y >>> CONFIG_PCI=y >>> CONFIG_PCI_DEVICES=y >>> CONFIG_PCI_TESTDEV=y >>> CONFIG_PCI_EXPRESS=y >>> CONFIG_PSERIES=y >>> CONFIG_SCSI=y >>> CONFIG_SPAPR_VSCSI=y >>> CONFIG_TEST_DEVICES=y >>> CONFIG_USB=y >>> CONFIG_USB_OHCI=y >>> CONFIG_USB_OHCI_PCI=y >>> CONFIG_USB_SMARTCARD=y >>> CONFIG_USB_STORAGE_CORE=y >>> CONFIG_USB_STORAGE_CLASSIC=y >>> CONFIG_USB_XHCI=y >>> CONFIG_USB_XHCI_NEC=y >>> CONFIG_USB_XHCI_PCI=y >>> CONFIG_VFIO=y >>> CONFIG_VFIO_PCI=y >>> CONFIG_VGA=y >>> CONFIG_VGA_PCI=y >>> CONFIG_VHOST_USER=y >>> CONFIG_VIRTIO_PCI=y >>> CONFIG_VIRTIO_VGA=y >>> CONFIG_WDT_IB6300ESB=y >>> CONFIG_XICS=y >>> CONFIG_XIVE=y >>> CONFIG_TPM=y >>> CONFIG_TPM_SPAPR=y >>> CONFIG_TPM_EMULATOR=y >>> EOF >>> >>> $ mkdir build >>> $ cd build >>> >> >> <snip> >> >>> $ ../configure --without-default-devices >>> --with-devices-ppc64=ppc64-rh-devices --target-list=ppc64-softmmu >>> $ make -j >>> ... >>> /usr/bin/ld: >>> libqemu-ppc64-softmmu.fa.p/monitor_misc.c.o:(.data.rel+0x3228): undefined >>> reference to `hmp_info_via' >>> collect2: error: ld returned 1 exit status >>> >>> Since TARGET_PPC is defined when building target ppc64-softmmu, the >>> hmp_info_via will be referenced when processing the hmp-commands-info.hx. >>> However, hmp_info_via implementation resides on hw/misc/mos6522.c, which is >>> built only if CONFIG_MOS6522 is defined, as per hw/misc/meson.build. >> >> I think this particular problem you hit is due to the 64 bit devices >> file including 32 bit as well: >> >> $ cat configs/devices/ppc64-softmmu/default.mak >> # Default configuration for ppc64-softmmu >> >> # Include all 32-bit boards >> include ../ppc-softmmu/default.mak <----- here >> >> # For PowerNV >> CONFIG_POWERNV=y >> >> # For pSeries >> CONFIG_PSERIES=y >> --- >> >> So ppc64-softmmu doesn't quite do what it says on the tin. I think in >> the long run we need to revisit the conversation about whether to keep >> the 32 & 64 bit builds separate. It is misleading that you're explicitly >> excluding ppc-softmmu from the `--target-list`, but a some 32 bit stuff >> still comes along implicitly. > > Unfortunately for historical reasons it isn't quite that simple: the mac99 > machine in > hw/ppc/mac_newworld.c is both a 32-bit and a 64-bit machine, but with a > different PCI > host bridge and a 970 CPU if run from qemu-system-ppc64. Unfortunately it > pre-dates > my time working on QEMU's PPC Mac machines but I believe it was (is?) capable > of > booting Linux, even though I doubt it accurately represents a real machine.
Well, what you describe is fine in my view, the 64-bit machine uses qemu-system-ppc64. If there is shared code with 32-bit, that is ok. What I would like to understand is what is the community's direction with this, do we want: 1) the 64-bit build to include all of the code and have it run all machines, or; 2) the 64-bit build to run only 64-bit machines and the 32-bit build to run only 32-bit machines. There are things such as 'target_ulong' that go against #1, and this thread shows that we're not doing #2 as well. I know there have been discussions about this in the past but I couldn't find them in the archives.
