qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Thomas Huth <thuth@redhat.com>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org, Peter Maydell <peter.maydell@linaro.org>
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	[thread overview]
Message-ID: <91b9cdcd-fe85-5283-8d03-c0e948f72f45@redhat.com> (raw)
In-Reply-To: <98da7855-40eb-2d58-8f0a-b75a041aba4c@redhat.com>

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 <thuth@redhat.com>
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	other threads:[~2019-08-29 18:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23 13:58 [Qemu-devel] [PATCH 0/4] Support disabling TCG on ARM (part 2) Philippe Mathieu-Daudé
2019-08-23 13:58 ` [Qemu-devel] [PATCH 1/4] target/arm: Restrict pre-ARMv7 cpus to TCG Philippe Mathieu-Daudé
2019-08-23 17:04   ` Richard Henderson
2019-08-29 18:04     ` Philippe Mathieu-Daudé
2019-08-23 13:58 ` [Qemu-devel] [PATCH 2/4] target/arm: Restrict R and M profiles " Philippe Mathieu-Daudé
2019-08-23 17:06   ` Richard Henderson
2019-08-23 13:58 ` [Qemu-devel] [PATCH 3/4] RFC target/arm: Do not build pre-ARMv7 cpus when using KVM Philippe Mathieu-Daudé
2019-08-23 14:28   ` Thomas Huth
2019-08-29 18:19     ` Philippe Mathieu-Daudé [this message]
2019-08-30  5:35       ` Thomas Huth
2019-08-23 17:12   ` Richard Henderson
2019-08-29 18:08     ` Philippe Mathieu-Daudé
2019-08-23 13:58 ` [Qemu-devel] [PATCH 4/4] RFC target/arm: Do not build A/M-profile " Philippe Mathieu-Daudé
2019-08-23 17:14   ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91b9cdcd-fe85-5283-8d03-c0e948f72f45@redhat.com \
    --to=philmd@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).