On 2023/11/22 14:25, Song Liu wrote:
On Mon, Nov 20, 2023 at 12:05 AM Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote:
On 2023/11/20 6:02, Song Liu wrote:
[...]
In contrast, our intended use case is more like a normal application.
So, for example, a user may download a container and run QEMU (including
the BPF program) installed in the container. As such, it is nice if the
ABI is stable across kernel releases, but it is not guaranteed for
kfuncs. Such a use case is already covered with the eBPF steering
program so I want to maintain it if possible.
TBH, I don't think stability should be a concern for kfuncs used by QEMU.
Many core BPF APIs are now implemented as kfuncs: bpf_dynptr_*,
bpf_rcu_*, etc. As long as there are valid use cases,these kfuncs will
be supported.
Documentation/bpf/kfuncs.rst still says:
> kfuncs provide a kernel <-> kernel API, and thus are not bound by any
> of the strict stability restrictions associated with kernel <-> user
> UAPIs.
Is it possible to change the statement like as follows:
"Most kfuncs provide a kernel <-> kernel API, and thus are not bound by
any of the strict stability restrictions associated with kernel <-> user
UAPIs. kfuncs that have same stability restrictions associated with
UAPIs are exceptional, and must be carefully reviewed by subsystem (and
BPF?) maintainers as any other UAPIs are."
I am afraid this is against the intention to not guarantee UAPI-level stability
for kfuncs.
Is it possible to ensure that a QEMU binary with the eBPF program
included works on different kernel versions without UAPI-level stability
then? Otherwise, I think we need to think of the minimal UAPI addition
that exposes the feature I propose, and the two options I presented
first are the candidates of such: the stable BPF change or tuntap
interface change.
Regards,
Akihiko Odaki
