> -----Original Message----- > From: Alex Bennée <alex.ben...@linaro.org> > Sent: Tuesday, February 16, 2021 5:18 AM > To: Philippe Mathieu-Daudé <f4...@amsat.org> > Cc: Brian Cain <bc...@quicinc.com>; qemu-devel@nongnu.org; Michael > Lambert <mlamb...@quicinc.com>; Sid Manning <sidn...@quicinc.com>; > Laurent Vivier <laur...@vivier.eu> > Subject: [EXT] Re: hexagon sysemu - library loading path feature > > > Philippe Mathieu-Daudé <f4...@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
