On 5/5/21 9:31 PM, Eduardo Habkost wrote: > 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?
I'd suggest to move the discussions about the ARM series to the arm series thread. I am concerned here about the groundwork and x86 part. Thanks, Claudio > > >> >> >> 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 >> >
