Claudio Fontana <cfont...@suse.de> writes: > On 1/10/23 15:02, Peter Maydell wrote: >> On Tue, 10 Jan 2023 at 13:36, Fabiano Rosas <faro...@suse.de> wrote: >>> >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>> >>>> On Tue, 10 Jan 2023 at 13:00, Fabiano Rosas <faro...@suse.de> wrote: >>>>> >>>>> Thomas Huth <th...@redhat.com> writes: >>>>> >>>>>> On 09/01/2023 23.42, Fabiano Rosas wrote: >>>>>>> From: Claudio Fontana <cfont...@suse.de> >>>>>>> >>>>>>> on ARM we currently list and build all machines, even when >>>>>>> building KVM-only, without TCG. >>>>>>> >>>>>>> Until we fix this (and we only list and build machines that are >>>>>>> compatible with KVM), only test specifically using the "virt" >>>>>>> machine in this case. >>>>>> >>>>>> Why don't you fix it immediately? ... >>>>> >>>>> My idea was to have in this series the minimum to unbreak the >>>>> --disable-tcg build and later bring the rest of the changes >>>>> incrementally. >>>> >>>> This test is basically checking "all the machines should >>>> work". That's an important invariant to maintain, so >>>> I don't think we should just skip it for Arm targets. >>> >>> But what does "all machines" mean in a no-TCG build? The original intent >>> of the patch was that only 'virt' should be present and therefore the >>> only one tested. >> >> It means "every machine the user can create". If the >> machine can't run then either we shouldn't compile it >> in, or else we should be compiling in enough extra stuff >> to allow it to work. >> >> -- PMM > > Hi, > > once upon a time there was a series by Philippe to accomplish that (KConfig) > right?
Is this it? https://www.mail-archive.com/qemu-devel@nongnu.org/msg777719.html I have now moved the cpus into the tcg directory: # ./qemu-system-aarch64 -cpu ? Available CPUs: a64fx cortex-a35 cortex-a53 cortex-a55 cortex-a57 cortex-a72 cortex-a76 host max neoverse-n1 What remains is changing the Kconfig to not bring all the machines. Nowadays for KVM is the 'virt' machine the only one we use? I did some tests yesterday by keeping only CONFIG_ARM_VIRT and was left with this: # ./qemu-system-aarch64 -machine ? Supported machines are: none empty machine virt-2.10 QEMU 2.10 ARM Virtual Machine virt-2.11 QEMU 2.11 ARM Virtual Machine virt-2.12 QEMU 2.12 ARM Virtual Machine virt-2.6 QEMU 2.6 ARM Virtual Machine virt-2.7 QEMU 2.7 ARM Virtual Machine virt-2.8 QEMU 2.8 ARM Virtual Machine virt-2.9 QEMU 2.9 ARM Virtual Machine virt-3.0 QEMU 3.0 ARM Virtual Machine virt-3.1 QEMU 3.1 ARM Virtual Machine virt-4.0 QEMU 4.0 ARM Virtual Machine virt-4.1 QEMU 4.1 ARM Virtual Machine virt-4.2 QEMU 4.2 ARM Virtual Machine virt-5.0 QEMU 5.0 ARM Virtual Machine virt-5.1 QEMU 5.1 ARM Virtual Machine virt-5.2 QEMU 5.2 ARM Virtual Machine virt-6.0 QEMU 6.0 ARM Virtual Machine virt-6.1 QEMU 6.1 ARM Virtual Machine virt-6.2 QEMU 6.2 ARM Virtual Machine virt-7.0 QEMU 7.0 ARM Virtual Machine virt-7.1 QEMU 7.1 ARM Virtual Machine virt-7.2 QEMU 7.2 ARM Virtual Machine virt QEMU 8.0 ARM Virtual Machine (alias of virt-8.0) virt-8.0 QEMU 8.0 ARM Virtual Machine x-remote Experimental remote machine But qtest dislikes that even more. I need to figure out why. The approach of that series seems interesting, moving CONFIG_FOO=y from default.mak into Kconfig as 'default y if TCG'. Maybe that will yield better results, I'll try to follow that route.
