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