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 <cfont...@suse.de> writes: > >> On 3/8/21 3:02 PM, Alex Bennée wrote: > >>> Claudio Fontana <cfont...@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-cfont...@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
