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

[Claudio Fontana]

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


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