softmmu vs sysemu [Was: Re: [RFC v1 06/38] target/arm: split off cpu-softmmu.c]

[Claudio Fontana <cfontana@suse.de>]

On 2/23/21 10:35 AM, Claudio Fontana wrote:
> On 2/23/21 10:16 AM, Philippe Mathieu-Daudé wrote:
>> On 2/23/21 9:55 AM, Claudio Fontana wrote:
>>> On 2/22/21 6:29 PM, Alex Bennée wrote:
>>>>
>>>> Claudio Fontana <cfontana@suse.de> writes:
>>>>
>>>>> From: Claudio Fontana <cfontana@centriq4.arch.suse.de>
>>>>>
>>>>> Signed-off-by: Claudio Fontana <cfontana@suse.de>
>>>>> ---
>>>>>  target/arm/internals.h   |   9 ++-
>>>>>  target/arm/cpu-softmmu.c | 134 +++++++++++++++++++++++++++++++++++++++
>>>>>  target/arm/cpu.c         |  95 ---------------------------
>>>>>  target/arm/meson.build   |   1 +
>>>>>  4 files changed, 143 insertions(+), 96 deletions(-)
>>>>>  create mode 100644 target/arm/cpu-softmmu.c
>>>>>
>>>>> diff --git a/target/arm/internals.h b/target/arm/internals.h
>>>>> index 6384461177..6589b63ebc 100644
>>>>> --- a/target/arm/internals.h
>>>>> +++ b/target/arm/internals.h
>>>>> @@ -1196,4 +1196,11 @@ static inline uint64_t useronly_maybe_clean_ptr(uint32_t desc, uint64_t ptr)
>>>>>      return ptr;
>>>>>  }
>>>>>  
>>>>> -#endif
>>>>> +#ifndef CONFIG_USER_ONLY
>>>>> +void arm_cpu_set_irq(void *opaque, int irq, int level);
>>>>> +void arm_cpu_kvm_set_irq(void *opaque, int irq, int level);
>>>>> +bool arm_cpu_virtio_is_big_endian(CPUState *cs);
>>>>> +uint64_t a15_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo *ri);
>>>>> +#endif /* !CONFIG_USER_ONLY */
>>>>> +
>>>>> +#endif /* TARGET_ARM_INTERNALS_H */
>>>>> diff --git a/target/arm/cpu-softmmu.c b/target/arm/cpu-softmmu.c
>>>>> new file mode 100644
>>>>> index 0000000000..263d1fc588
>>>>> --- /dev/null
>>>>> +++ b/target/arm/cpu-softmmu.c
>>>>> @@ -0,0 +1,134 @@
>>>>> +/*
>>>>> + * QEMU ARM CPU
>>>>
>>>> I guess apropos the discussion earlier it's really cpu-sysemu.c and we
>>>> could expand the header comment.
>>>>
>>>>   QEMU ARM CPU - Helpers for system emulation and KVM only
>>>>
>>>> <snip>
>>>>
>>>> Otherwise:
>>>>
>>>> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
>>>>
>>>
>>> Should I rename all *softmmu in the series to "sysemu"?
>>>
>>> I wonder if we should take the issue of sysemu/system/softmmu topic into a separate series.
>>> Currently basically starting from the build system already, "softmmu", sysemu and system are treated as a single thing, and the convention from build system and directories seems to be "softmmu",
>>> while from the header files we get "sysemu/".
>>>
>>> I agree that this is not a sufficient model to account for the new feature that Richard wants to develop,
>>> I just suggest we could also consider tackling this separately, with a pass through the whole code, gathering more input in the context of a dedicated series.
>>>
>>> What do you think?
>>
>> This is a valid reasoning. However I have my doubts "doing
>> that later" will ever be done/finished (not related to you
>> Claudio in particular, but with dealing with all subsystems).

I went through this again, and looked at the todo.

Already just at the meson level, in the previous i386 series, the changes to split real softmmu (CONFIG_SOFTMMU?) and sysemu would be required.

Otherwise I don't feel so comfortable adding a half-baked discrepancy from the current convention, which is consistent
(even if "wrong", or "whose model is insufficiently detailed" to be able to implement new features).

If we don't believe that the work of splitting semantically real softmmu and sysemu would ever be completed,
why start in the middle of this series? The risk would then result in a worse situation than the current one I think,
with an even less homogeneous code base.

Could this work not be done independently of this series (and I could rebase on that if necessary),
and pushed by who really understand the problem? Probably starting from meson, configure, ...
I could help reviewing there, but probably I am not the best person to push it.

Why are we not confident that this can be done?


>>
>> Personally I'd rather see this sorted out with the arm target
>> then once done propose it as an example to the other ones.
>> You already considered the most complex cases, x86 and arm :)


I mean, after we have split the code a bit more properly, renaming the additional mentions of "softmmu" to "sysemu" should not be hard.
Or, we could do the softmmu vs sysemu split first, and I rebase on top of that.


> 
> 
> Ok, if there are no other comments I would go with "sysemu", just because "system" is a bit too much of a loaded word,
> and we have the precedent of include/sysemu/ .


I am all for "just getting it done", but here the i386 and the arm series become a mixture of things that I am not comfortable with,
I'd prefer a dedicated series..


>>> Also Paolo, any comments, since softmmu is all over meson?
>>>
> 
> And Peter, any comments, preference?
> 


Maybe let us give some more time for more comments to flow in?


Thanks,


Claudio