On 2023/11/22 14:25, Song Liu wrote:
On Mon, Nov 20, 2023 at 12:05 AM Akihiko Odaki akihiko.odaki@daynix.com 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