qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/4] RFC target/arm: Do not build pre-ARMv7 cpus


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH 3/4] RFC target/arm: Do not build pre-ARMv7 cpus when using KVM
Date: Thu, 29 Aug 2019 20:19:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

Hi Thomas,

On 8/23/19 4:28 PM, Thomas Huth wrote:
> On 8/23/19 3:58 PM, Philippe Mathieu-Daudé wrote:
>> A KVM-only build won't be able to run pre-ARMv7 cpus, disable them.
>>
>> If KVM is not enabled, they are enabled by default.
> [...]
>>  config CHEETAH
>>      bool
>> +    select ARM_V4
>>      select OMAP
>>      select TSC210X
> 
> Are you sure about the "enabled by default" ? There is not "default y"
> here, is it?

What I mean is if you build with --disable-kvm, this selects
--enable-tcg which provides the pre-ARMv7 cpus. So to make no changes, I
also added:

  config ARM_V4
      default y

Which include the "default y".

> 
> Also I'm not sure whether it's such a good idea to always disable the
> config switches in default-configs/arm-softmmu.mak ... if somebody wants
> to build such a restricted QEMU, don't they have to maintain their own
> set of config files anyway?

Ah... I followed your example:

$ git show 9e5c2056d1e
commit 9e5c2056d1e80f344a0c412d7a3d847db1f4e034
Author: Thomas Huth <address@hidden>
Date:   Tue Jan 29 10:42:14 2019 +0100

    s390x: express dependencies with Kconfig

    Instead of hard-coding all config switches in the config file
    default-configs/s390x-softmmu.mak, let's use the new Kconfig files
    to express the necessary dependencies: The S390_CCW_VIRTIO config switch
    for the "s390-ccw-virtio" machine now selects all non-optional devices.

    And since we already have the VIRTIO_PCI and VIRTIO_MMIO config switches
    for the other two virtio transports, this patch also introduces a new
    config switch VIRTIO_CCW for the third, s390x-specific virtio transport,
    so that all three virtio transports are now handled in the same way.

diff --git a/default-configs/s390x-softmmu.mak
b/default-configs/s390x-softmmu.mak
@@ -1,9 +1,13 @@
-CONFIG_PCI=y
-CONFIG_VIRTIO_PCI=y
-CONFIG_SCLPCONSOLE=y
-CONFIG_TERMINAL3270=y
-CONFIG_S390_FLIC=y
-CONFIG_WDT_DIAG288=y
+# Default configuration for s390x-softmmu
+
+# Uncomment the following lines to disable these optional devices:
+#
+#CONFIG_TERMINAL3270=n
+#CONFIG_VFIO_AP=n
+#CONFIG_VFIO_CCW=n
+#CONFIG_VIRTIO_PCI=n
+#CONFIG_WDT_DIAG288=n
+
+# Boards:
+#
 CONFIG_S390_CCW_VIRTIO=y
-CONFIG_VFIO_CCW=y
-CONFIG_VFIO_AP=y

OK now I see, I should have added your comment and use the opposite form
(because now these boards are all enabled) so 's/=y/=n' in my patch.

> I think we should maybe rather rework the default-configs directory:
> Rename the default to "config/default/" instead and then we can add
> other subfolders with such special configurations, e.g. config/nemu/ or
> config/lean-kvm/ or however you want to call it. Then add a new switch
> to the configure script to be able to use the configs from such a
> different folder.

OK so if someone wants a special config, he'd know the config values to
select, so it is pointless/confusing to keep them commented.
Are you suggesting to simply remove the default entries? Such:

-- >8 --
@@ -9,34 +9,33 @@ CONFIG_ARM_V7M=y
 CONFIG_ARM_VIRT=y
 CONFIG_CUBIEBOARD=y
 CONFIG_EXYNOS4=y
-CONFIG_HIGHBANK=y
-CONFIG_INTEGRATOR=y
 CONFIG_FSL_IMX31=y
-CONFIG_MUSICPAL=y
 CONFIG_MUSCA=y
-CONFIG_CHEETAH=y
-CONFIG_SX1=y
-CONFIG_NSERIES=y
 CONFIG_STELLARIS=y
 CONFIG_REALVIEW=y
-CONFIG_VERSATILE=y
 CONFIG_VEXPRESS=y
 CONFIG_ZYNQ=y
-CONFIG_MAINSTONE=y
-CONFIG_GUMSTIX=y
-CONFIG_SPITZ=y
-CONFIG_TOSA=y
-CONFIG_Z2=y
-CONFIG_COLLIE=y
-CONFIG_ASPEED_SOC=y
 CONFIG_NETDUINO2=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
-CONFIG_DIGIC=y
 CONFIG_SABRELITE=y
 CONFIG_EMCRAFT_SF2=y
-CONFIG_MICROBIT=y
-CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
 CONFIG_SEMIHOSTING=y
---

Thanks,

Phil.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]