On Mon, Jan 23, 2017 at 05:02:02PM -0800, Alexei Starovoitov wrote: > > Another issue is around host/guest ABI. Guest BPF could add new features > > at any point. What if hypervisor can not support it all? I guess we > > could try loading program into hypervisor and run it within guest on > > failure to load, but this ignores question of cross-version > > compatibility - someone might start guest on a new host > > then try to move to an old one. So we will need an option > > "behave like an older host" such that guest can start and then > > move to an older host later. This will likely mean > > implementing this validation of programs in qemu userspace unless linux > > can supply something like this. Is this (disabling some features) > > something that might be of interest to larger bpf community? > > In case of x86->nic offload not all xdp features will be supported > by the nic and that is expected. The user will request 'offload of xdp prog' > in some form and if it cannot be done, then xdp programs will run > on x86 as before. Same thing, I imagine, is applicable to virtio->host > offload. Therefore I don't see a need for user space visible > feature negotiation.
Not userspace visible - guest visible. As guests move between hosts, you need to make sure source host does not commit to a feature that destination host does not support. -- MST
