hexagon sysemu - library loading path feature

hexagon sysemu - library loading path feature

[Brian Cain]

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.

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.

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?

-Brian

Re: hexagon sysemu - library loading path feature

[Philippe Mathieu-Daudé]

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

Re: hexagon sysemu - library loading path feature

[Alex Bennée]

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?

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

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

>> 
>> -Brian
>> 


-- 
Alex Bennée

RE: hexagon sysemu - library loading path feature

[Brian Cain]

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