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

[Eduardo Habkost]

On Wed, May 05, 2021 at 02:15:29PM +0200, Philippe Mathieu-Daudé wrote:
> 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?

I don't get it.  Why exactly QOM interfaces can't be
Kconfig-selected out?

Do you want to be able to compile out an interface while not
compiling out types that implement that interface?  Why?


> 
> 
> 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
> 

-- 
Eduardo