RE: hexagon sysemu - library loading path feature

[Brian Cain <bcain@quicinc.com>]

> -----Original Message-----
> From: Alex Bennée <alex.bennee@linaro.org>
> Sent: Tuesday, February 16, 2021 5:18 AM
> To: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Cc: Brian Cain <bcain@quicinc.com>; qemu-devel@nongnu.org; Michael
> Lambert <mlambert@quicinc.com>; Sid Manning <sidneym@quicinc.com>;
> Laurent Vivier <laurent@vivier.eu>
> Subject: [EXT] Re: hexagon sysemu - library loading path feature
>
>
> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
>
> > Cc'ing Laurent and Alex.
> >
> > On 12/17/20 6:14 AM, Brian Cain wrote:
> >> My team is working on sysemu support for Hexagon.  We've made some
> good progress so far and we'll work on upstreaming after Taylor’s hexagon
> linux-user patch series lands.
> >>
> >> The only use case we have focused on with sysemu is booting/running elf
> programs.  Both "-device loader,file=..." or "-kernel" are effective and work
> similarly.  We have implemented "angel calls" (semihosting) to do host I/O.
> We have not yet tried using the QEMU semihosting features/cmdline args, but
> may explore that option.
> >>
> >> One feature we'd like to integrate is a guest library search path
> >> feature.  The existing hexagon simulator program distributed in the
> >> Hexagon SDK has a command line option, “--usefs".  The manual states
> >> that it “Cause[s] the simulator to search for files in the directory
> >> with the specified path. It is used for accessing shared object files
> >> that are loaded during program execution.”  If the guest OS has a
> >> loader that tries to resolve an executable or library's DT_NEEDED
> >> shared object libraries, we would want QEMU angel calls to be able to
> >> search a user specified host-path for the toolchain language support
> >> libraries.
>
> The current semihosting syscall ABI basically relies on the CWD of the either
> the QEMU binary or the GDB process (if routing semihosting via the gdbstub).
>
> Are the Hexagon angel calls the same are ARM semihosting or are they there
> own thing? Can you point me at a spec?

I will look for a specification.  It may have been loosely modeled on ARM's, I'm not sure.

> >> This feature is like the functionality in QEMU’s “QEMU_LD_PREFIX”
> >> environment variable used by linux-userspace.  So, one idea was to
> >> just (ab)use this interface to mean the same thing for sysemu.  We
> >> could make it a target-specific hexagon feature, if it doesn’t make
> >> sense to have it as target-independent.  And if it makes sense we
> >> could qualify it like HEXAGON_QEMU_LD_PREFIX.
>
> Let's leave QEMU_LD_PREFIX to user-space. We try and avoid adding new
> environment variables - especially to system emulation. I think this is
> something to expose via a properly modelled QOM property which then can
> be tweaked via command line or HMP/QMP.

Ok, that makes sense.

> >> If not this environment variable, is there an existing QEMU feature
> >> that maps well here?  Or is there a better interface that we should
> >> consider instead?
>
> Not really - we virtiofs but that is a guest visible device that allows file-system
> pass-through to the host. However it does broadly assume a Linux guest
> (although there is no reason it has to).

I don’t think virtiofs will suit the need here.  It's not preferred, but we could explore an approach that requires guest code to change.  I will discuss with the team and see if we can offer some proposals.

-Brian