Re: [PATCH v4 0/1] contrib/plugins: add dlcall to call host functions from a guest

["Alex Bennée" <alex.bennee@linaro.org>]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 6/30/2026 6:48 PM, Ziyang Zhang wrote:
>> Hi Pierrick,
>> 
>> Thanks for the review, and for thinking about the end-user experience.
>> 
>> On Tue, 30 Jun 2026 12:34:59 -0700, Pierrick Bouvier wrote:
>>> Thanks for publishing it.
>>>
>>> A few ideas to make Lorelei even more easy to use:
>>>
>>> Would that be possible to add binary artifacts to the existing 1.0.0
>>> Lorelei release?
>>> Ideally, it should provide a toolchain (for x64 hosts) with support for
>>> x64, arm64 and riscv64 guest thunks.
>>>
>>> Also, would that possible to provide a script to generate boilerplate
>>> for thunks, and extract list of symbols from a given library?
>>>
>>> My ultimate goal would be to have something as simple as:
>>> $ wget toolchain.hostx64.tar.gz
>>>
>>> # automatically generate boilerplate + compile guest/host thunks
>>> $ toolchain.hostx64/bin/generate-thunks \
>>>    --arch arm64 --library /usr/lib/libfoo.so \
>>>    --header /usr/include/foo.h --out thunks_arm64
>>>
>>> $ aarch64-linux-gnu-gcc main.c -lfoo
>>> $ env LD_LIBRARY_PATH=./thunks_arm64 \
>>>    qemu-arm64 ./a.out -plugin contrib/plugins/liblorelei.so
>>>
>>> I understand it asks for more, but we really need to make lorelei as
>>> simple to use as possible, without pushing the internal details to users.
>>>
>>> What do you think about this?
>> 
>> 
>> Prebuilt toolchain / instant acceleration
>> 
>> Agreed: the goal is to install it and feel the speedup right away,
>> with no build step. I'll do this, but as a point release on top of
>> 1.0.0.0 rather than in the initial tag, so it lands as its own
>> increment. The model is FEX's FEXFetchRootFS: a prebuilt host
>> toolchain plus ready-made thunks, so a user goes from download
>> straight to an accelerated guest. Like FEXFetchRootFS, the tool will
>> likely have the user pick their distribution and version, because a
>> thunk is bound to a specific library build: the exported symbols, and
>> sometimes the ABI, differ across distros and releases, so the prebuilt
>> thunks must match the host's real libraries.
>> 
>> Generating thunks for a new library
>> 
>> One caveat on the generate-thunks sketch. Lorelei guarantees that
>> thunk *generation* is automatic and reproducible: once a library is
>> described, TLC deterministically emits both sides, including the
>> callback and variadic cases. What it cannot do on its own is
>> *describe* the library, that is, pick the symbols you need and write
>> descriptors for the ones that do not marshal trivially (callbacks by
>> pointer, ownership crossing the boundary). Those stay judgment calls
>> that need a human, or an AI, in the loop.
>> 
>> So adding a new library is not one fully automatic command. What
>> Lorelei does is drastically cut the effort versus hand-writing every
>> thunk the way Box64 does: the generate-thunks helper automates what
>> is automatable (symbol extraction, boilerplate, building both sides),
>> so simple libraries are close to one-shot and harder ones start from
>> a skeleton rather than a blank file.
>> 
>> Plugin name
>> 
>> I would rather keep "dlcall" than rename it to "lorelei". The plugin
>> defines a general interface (the magic-syscall dlopen/dlsym/invoke
>> ABI), and Lorelei is only one userspace implementation of it now:
>> 
>>   - "dlcall" says what the plugin does and is understood without
>>     leaving the tree. "lorelei" names an external project and says
>>     nothing about the mechanism.
>>   - An in-tree interface should not be tied to the branding or
>>     lifetime of an out-of-tree project. If Lorelei is renamed,
>>     forked, or joined by other toolchains, the name becomes
>>     misleading.
>>   - Naming it after one implementation implies it is the blessed one
>>     and discourages alternatives. A generic name keeps QEMU neutral.
>>   - It also matches how the other contrib plugins are named, by
>>     functionality (lockstep, cache, ...).
>>
>
> I agree with your arguments, let's keep this name then.
>
>> I do agree Lorelei should be discoverable from the tree, so I'll add
>> docs to docs/about/emulation.rst that introduce the dlcall interface
>> and point at Lorelei as a ready-to-use implementation, with a minimal
>> example and without the internal details.
>> 
>> Does that sound reasonable?
>>
>
> Yes sounds good to me!

Sounds good to me as well ;-)

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro