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

[Philippe Mathieu-Daudé]

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