Re: [PATCH v26 00/20] i386 cleanup PART 2

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 5/5/21 12:04 PM, Alex Bennée wrote:
> Claudio Fontana <cfontana@suse.de> writes:
>> On 3/8/21 3:02 PM, Alex Bennée wrote:
>>> Claudio Fontana <cfontana@suse.de> writes:
>>>
>>>> Hi,
>>>>
>>>> anything else for me to do here?
>>>
>>> It looks to me that this series is looking pretty good. Every patch has
>>> at least one review so I think it's just waiting on the maintainers to
>>> pick it up.
>>>
>>> Paolo/Richard - are you intending to take the series as is or are you
>>> waiting for something else? I'd like to see the patch delta reduced for
>>> the ARM cleanup work which is still ongoing.
>>
>> I am a bit at a loss here, as this has been reviewed for a while, but nothing is happening.
>> Rebasing is starting to become more and more draining;
> 
> This is still the latest re-factor right?
> 
>   Subject: [PATCH v28 00/23] i386 cleanup PART 2
>   Date: Mon, 22 Mar 2021 14:27:36 +0100
>   Message-Id: <20210322132800.7470-1-cfontana@suse.de>
> 
>> I am seeing some changes from Phil that redo some of the patches here (like target arch user),
>> maybe you would like to drive this?
> 
> AIUI his changes where to get qtest passing.

I hadn't read Claudio's mail, I think he's mentioning commit 46369b50ee3

    meson: Introduce meson_user_arch source set for arch-specific user-mode

    Similarly to the 'target_softmmu_arch' source set which allows
    to restrict target-specific sources to system emulation, add
    the equivalent 'target_user_arch' set for user emulation.

The patch only contains 6 lines in 2 hunks, if it introduced a conflict
it should be trivial to resolve (I wasn't expecting it to conflict with
your work when I merged it TBH).

> I've just been chatting to
> Paolo on IRC so I think we are almost ready to go.
> 
>   > bonzini_: what's currently holding up getting Claudio's re-factoring
>       work merged?
>   > f4bug: also ^ - I'm a little worried we have splintering
>       re-factoring forks
>   *** First activity: f4bug joined 2 hours 8 minutes 6 seconds ago.
>   <f4bug> stsquad: the qtests series is pending imammedo review then
>       could go in
>   <f4bug> stsquad: which would simplify a bit Claudio's series (on
>       respin he could drop a pair of patches)
>   <f4bug> stsquad: my understanding was bonzini_ would merge the x86
>       series, then pm215 could merge the arm one on top
>   *** First activity: bonzini_ joined 1 hour 17 minutes 25 seconds ago.
>   <bonzini_> ok i can queue it in my next PR
>   <f4bug> the only blocking part is qtest not passing, but Claudio's
>       refactor series is not the culprit
>   <bonzini_> ok

I was referring to:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg804015.html

Then these aren't required:
- tests: restrict TCG-only arm-cpu-features tests to TCG builds
- tests: device-introspect-test: cope with ARM TCG-only devices

These could be reworked to use qtest_has_accel() instead of the
/* XXX */ comments:
- tests: do not run test-hmp on all machines for ARM KVM-only
- tests: do not run qom-test on all machines for ARM KVM-only

I didn't noticed the following patch had its content changed:
Revert "target/arm: Restrict v8M IDAU to TCG"
So now this is not a full revert, only the TYPE_IDAU_INTERFACE
type is moved back.

While this fixes the build, we still have a QOM design problem.
QOM interfaces can't be Kconfig-selected out. <- Eduardo, Markus?


More generally I think more code should be automatically stripped
out by Kconfig instead. In [1,2] I suggested to tie accel-specific
Kconfig selectors:

  config ARM_V7R
    bool
    depends on TCG && ARM

  config ARM_V7M
    bool
    depends on TCG && ARM
    select PTIMER

  config XLNX_ZYNQMP_ARM
    bool
    default y if TCG && AARCH64

But this can certainly be done on top of Claudio's work.

[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg777710.html
[2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg777719.html