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 <ehabk...@redhat.com>
>>>>>
>>>>> Signed-off-by: Eduardo Habkost <ehabk...@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é <phi...@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
>
