All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Claudio Fontana <cfontana@suse.de>,
	Eduardo Habkost <ehabkost@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Emilio G . Cota" <cota@braap.org>, Paul Durrant <paul@xen.org>,
	Jason Wang <jasowang@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
	Dario Faggioli <dfaggioli@suse.com>,
	Roman Bolshakov <r.bolshakov@yadro.com>,
	Cameron Esfahani <dirty@apple.com>,
	haxm-team@intel.com, Wenchao Wang <wenchao.wang@intel.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Bruce Rogers <brogers@suse.com>, Olaf Hering <ohering@suse.de>,
	Colin Xu <colin.xu@intel.com>
Subject: Re: [RFC v7 15/22] cpu: Move tlb_fill to tcg_ops
Date: Fri, 4 Dec 2020 20:27:52 +0100	[thread overview]
Message-ID: <bfdb4225-2104-bee7-ea81-3e687141c1f0@redhat.com> (raw)
In-Reply-To: <dc731d70-cf85-0735-4335-44f685343a9b@suse.de>

On 12/4/20 7:14 PM, Claudio Fontana wrote:
> On 12/4/20 7:00 PM, Philippe Mathieu-Daudé wrote:
>> On 12/4/20 6:37 PM, Eduardo Habkost wrote:
>>> On Fri, Dec 04, 2020 at 06:14:07PM +0100, Philippe Mathieu-Daudé wrote:
>>>> On 11/30/20 3:35 AM, Claudio Fontana wrote:
>>>>> From: Eduardo Habkost <ehabkost@redhat.com>
>>>>>
>>>>> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>>>>> ---
>>>>>  accel/tcg/cputlb.c              |  6 +++---
>>>>>  accel/tcg/user-exec.c           |  6 +++---
>>>>>  include/hw/core/cpu.h           |  9 ---------
>>>>>  include/hw/core/tcg-cpu-ops.h   | 12 ++++++++++++
>>>>>  target/alpha/cpu.c              |  2 +-
>>>>>  target/arm/cpu.c                |  2 +-
>>>>>  target/avr/cpu.c                |  2 +-
>>>>>  target/cris/cpu.c               |  2 +-
>>>>>  target/hppa/cpu.c               |  2 +-
>>>>>  target/i386/tcg-cpu.c           |  2 +-
>>>>>  target/lm32/cpu.c               |  2 +-
>>>>>  target/m68k/cpu.c               |  2 +-
>>>>>  target/microblaze/cpu.c         |  2 +-
>>>>>  target/mips/cpu.c               |  2 +-
>>>>>  target/moxie/cpu.c              |  2 +-
>>>>>  target/nios2/cpu.c              |  2 +-
>>>>>  target/openrisc/cpu.c           |  2 +-
>>>>>  target/ppc/translate_init.c.inc |  2 +-
>>>>>  target/riscv/cpu.c              |  2 +-
>>>>>  target/rx/cpu.c                 |  2 +-
>>>>>  target/s390x/cpu.c              |  2 +-
>>>>>  target/sh4/cpu.c                |  2 +-
>>>>>  target/sparc/cpu.c              |  2 +-
>>>>>  target/tilegx/cpu.c             |  2 +-
>>>>>  target/tricore/cpu.c            |  2 +-
>>>>>  target/unicore32/cpu.c          |  2 +-
>>>>>  target/xtensa/cpu.c             |  2 +-
>>>>>  27 files changed, 41 insertions(+), 38 deletions(-)
>>>>
>>>> With cc->tcg_ops.* guarded with #ifdef CONFIG_TCG:
>>>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>
>>> Thanks!
>>>
>>> Are the #ifdefs a hard condition for your Reviewed-by?
>>
>> No, as you said, this is fine as a first step, so you can
>> include them.
>>
>>> Even if we agree #ifdef CONFIG_TCG is the way to go, I don't
>>> think this should block a series that's a step in the right
>>> direction.  It can be done in a separate patch.
>>>
>>> (Unless the lack of #ifdef introduces regressions, of course)
>>
>> I'm worried about the +system -tcg build configuration.
>>
>> s390x is the only target testing for such regressions
>> (see "[s390x] Clang (disable-tcg)" on Travis-CI.
>>
> 
> which exact configure options are concerned about?
> 
> --disable-tcg --enable-kvm --target="*-system"?
> 
> Or something else?

Basically --disable-tcg --enable-$ACCEL [--enable-$ACCEL]

> 
> this is something I am testing (and found the issues).
> 
> I am currently testing (and a result fixing) for each patch:
> 
> --disable-tcg --enable-kvm

This one is meaningful to check the host, so I run it on:
- x86 [ok]
- s390x [ok]
- aarch64 [done, waiting for your effort before respining]
- ppc64 [done, I was postponing the series submission waiting
         for aa64 to be merged, but I might go back to it as
         aa64 is taking too long].
- mips: no hardware access

> --enable-tcg --disable-kvm
> --enable-tcg --enable-kvm --enable-hax
> --disable-system

I also use:

* --disable-tcg --disable-kvm --enable-xen
  [x86 host works]
  [aa64 host needs Alex Bennée patches]

* --disable-tcg --disable-system --disable-user --enable-tools

* --disable-system --static --disable-capstone
(experimental, not supported, don't waste time with it).

The most useful is --enable-tools with all accelerators disabled,
as it quickly triggers linking errors when you miss-place a
handler between #ifdefs.

> With targets (when compatible):
> TARGET_LIST="x86_64-softmmu,x86_64-linux-user,arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user,s390x-softmmu,s390x-linux-user"

"first class KVM users" include PPC64 too.

> 
> and yes, should offload much of this to CI..
> 
> Ciao,
> 
> Claudio
> 



  reply	other threads:[~2020-12-04 20:35 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30  2:35 [RFC v7 00/22] i386 cleanup Claudio Fontana
2020-11-30  2:35 ` [RFC v7 01/22] i386: move kvm accel files into kvm/ Claudio Fontana
2020-11-30  2:35 ` [RFC v7 02/22] i386: move whpx accel files into whpx/ Claudio Fontana
2020-11-30  2:35 ` [RFC v7 03/22] i386: move hax accel files into hax/ Claudio Fontana
2020-11-30  2:35 ` [RFC v7 04/22] i386: hvf: remove stale MAINTAINERS entry for old hvf stubs Claudio Fontana
2020-11-30  2:35 ` [RFC v7 05/22] i386: move TCG accel files into tcg/ Claudio Fontana
2020-11-30  2:35 ` [RFC v7 06/22] i386: move cpu dump out of helper.c into cpu-dump.c Claudio Fontana
2020-11-30  2:35 ` [RFC v7 07/22] i386: move TCG cpu class initialization out of helper.c Claudio Fontana
2020-11-30  2:35 ` [RFC v7 08/22] tcg: cpu_exec_{enter,exit} helpers Claudio Fontana
2020-11-30  2:35 ` [RFC v7 09/22] tcg: make CPUClass.cpu_exec_* optional Claudio Fontana
2020-11-30  2:35 ` [RFC v7 10/22] tcg: Make CPUClass.debug_excp_handler optional Claudio Fontana
2020-11-30  2:35 ` [RFC v7 11/22] cpu: Remove unnecessary noop methods Claudio Fontana
2020-11-30  2:35 ` [RFC v7 12/22] cpu: Introduce TCGCpuOperations struct Claudio Fontana
2020-12-04 17:10   ` Philippe Mathieu-Daudé
2020-12-04 17:28     ` Eduardo Habkost
2020-12-04 18:04       ` Claudio Fontana
2020-12-04 18:07         ` Claudio Fontana
2020-12-04 18:29           ` Eduardo Habkost
2020-12-04 18:02     ` Claudio Fontana
2020-11-30  2:35 ` [RFC v7 13/22] cpu: Move synchronize_from_tb() to tcg_ops Claudio Fontana
2020-12-04 17:12   ` Philippe Mathieu-Daudé
2020-11-30  2:35 ` [RFC v7 14/22] cpu: Move cpu_exec_* " Claudio Fontana
2020-12-04 17:13   ` Philippe Mathieu-Daudé
2020-11-30  2:35 ` [RFC v7 15/22] cpu: Move tlb_fill " Claudio Fontana
2020-12-04 17:14   ` Philippe Mathieu-Daudé
2020-12-04 17:37     ` Eduardo Habkost
2020-12-04 18:00       ` Philippe Mathieu-Daudé
2020-12-04 18:14         ` Claudio Fontana
2020-12-04 19:27           ` Philippe Mathieu-Daudé [this message]
2020-12-05 10:06             ` Claudio Fontana
2020-12-04 18:09       ` Claudio Fontana
2020-11-30  2:35 ` [RFC v7 16/22] cpu: Move debug_excp_handler " Claudio Fontana
2020-11-30  2:35 ` [RFC v7 17/22] accel: extend AccelState and AccelClass to user-mode Claudio Fontana
2020-11-30  2:35 ` [RFC v7 18/22] accel: replace struct CpusAccel with AccelOpsClass Claudio Fontana
2020-11-30  2:35 ` [RFC v7 19/22] accel: introduce AccelCPUClass extending CPUClass Claudio Fontana
2020-11-30  2:35 ` [RFC v7 20/22] i386: split cpu accelerators from cpu.c, using AccelCPUClass Claudio Fontana
2020-11-30  2:35 ` [RFC v7 21/22] cpu-exec: refactor realizefn for all targets Claudio Fontana
2020-11-30  2:35 ` [RFC v7 22/22] cpu: introduce cpu_accel_instance_init Claudio Fontana
2020-12-04 13:54 ` [RFC v7 00/22] i386 cleanup [hw/core/cpu.c common] Claudio Fontana
2020-12-04 13:55   ` Claudio Fontana
2020-12-04 16:07   ` Paolo Bonzini
2020-12-04 17:34     ` Eduardo Habkost
2020-12-04 17:59     ` Claudio Fontana

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=bfdb4225-2104-bee7-ea81-3e687141c1f0@redhat.com \
    --to=philmd@redhat.com \
    --cc=anthony.perard@citrix.com \
    --cc=brogers@suse.com \
    --cc=cfontana@suse.de \
    --cc=colin.xu@intel.com \
    --cc=cota@braap.org \
    --cc=dfaggioli@suse.com \
    --cc=dirty@apple.com \
    --cc=ehabkost@redhat.com \
    --cc=haxm-team@intel.com \
    --cc=jasowang@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=ohering@suse.de \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=r.bolshakov@yadro.com \
    --cc=richard.henderson@linaro.org \
    --cc=sstabellini@kernel.org \
    --cc=sunilmut@microsoft.com \
    --cc=thuth@redhat.com \
    --cc=wenchao.wang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.