Re: [PATCH 0/5] semihosting: Reduce target specific code

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

+Paolo & Marc-André Lureau for chardev backend.

On 8/1/25 23:53, Richard Henderson wrote:
> On 1/8/25 07:26, Alex Bennée wrote:
>> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
>>
>>> This series makes semihosting config.c and console.c
>>> target agnostic, building them once, removing symbol
>>> collision of the following functions in the single
>>> binary:
>>
>> Queued to semihosting/next, thanks.
>>
>>>   - qemu_semihosting_chardev_init
>>>   - qemu_semihosting_config_options
>>>   - qemu_semihosting_config_opts
>>>   - qemu_semihosting_enable
>>>   - semihosting_arg_fallback
>>>   - semihosting_enabled
>>>   - semihosting_get_argc
>>>   - semihosting_get_target
>>>
>>> This function is still problematic, being built for
>>> each target:
>>>
>>>   - qemu_semihosting_guestfd_init
>>>
>>> Note, it depends on CONFIG_ARM_COMPATIBLE_SEMIHOSTING
>>> which is target specific, so doesn't scale in a
>>> heterogeneous setup like the ZynqMP machine, having
>>> ARM cores with CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y and
>>> MicroBlaze ones with CONFIG_ARM_COMPATIBLE_SEMIHOSTING=n.
>>
>> Does MicroBlaze even do semihosting?
>>
>>> I suppose the semihosting API needs rework to consider
>>> the CPUClass? I'll let that investigation for the
>>> maintainer ;)
>>
>> Hmm most of it is already handled as EXCP_SEMIHOST exceptions are dealt
>> with withing the target specific exception handlers.
>> do_common_semihosting could be renamed though - do_armc_semihosting()
>> maybe?
>>
>> If we have the full list of CPUs at qemu_semihosting_chardev_init() time
>> we could then selectively do the bits of qemu_semihosting_guestfd_init()
>> depending on what combination we have. For normal open/read/write stuff
>> I think they could co-exist.
>>
>> Two independent cores could still write to stdout (0) though. Fixing
>> that would need a per-cpu semihosting config.

What I'd expect here is one VC per semihosting context stdout. If we
want to mux, we use the chardev mux.

Anyhow this in particular is not a blocker, it was just an opened
question.

> None of the semihosting stuff is smp safe.
> 
> The assumption in the homogeneous cpu case is that the guest uses it's 
> own mutexes to protect the semihosting calls.  This is obviously more 
> complicated in the heterogeneous case, but it *still* should not be 
> qemu's problem.

FYI the use case requested is $n Hexagon cores writing to $n semihosting
file descriptors, and a user-mode process on an ARM core able to read
each of these FDs.

Regards,

Phil.