On Wed, Jan 25, 2017 at 10:41:24AM +0800, Jason Wang wrote: > > > On 2017年01月24日 05:40, Michael S. Tsirkin wrote: > > I've been thinking about passing XDP programs from guest to the > > hypervisor. Basically, after getting an incoming packet, we could run > > an XDP program in host kernel. > > > > If the result is XDP_DROP or XDP_TX we don't need to wake up the guest at > > all! > > Interesting, but there're some questions: > > - This may work well for XDP_DROP and XDP_TX, and manage to work for > XDP_PASS. But what if XDP were extend for other capabilities in the future? > E.g forward to other interface or userspace?
This is exactly what I am saying. Any future extensions will need feature negotiation. > - For XDP_DROP, it can be done through socket filter. > - Need to translate XDP_TX as something like XDP_RX at least for tun. Or it > may bring some confusion if tun support XDP or XDP were supported in tx > patch in the future. > > > > > When using tun for networking - especially with adjust_head - this > > unfortunately probably means we need to do a data copy unless there is > > enough headroom. How much is enough though? > > Not a tun specific issue I believe? It is tun specific because tun gets skbs from linux net core while XDP expects pre-skb pages. > > > > 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. > > I'm suspect whether or not this can be done easily. > > > 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? > > > > With a device such as macvtap there exist configurations where a single > > guest is in control of the device (aka passthrough mode) in that case > > there's a potential to run xdp on host before host skb is built, unless > > host already has an xdp program attached. If it does we could run the > > program within guest, but what if a guest program got attached first? > > Maybe we should pass a flag in the packet "xdp passed on this packet in > > host". Then, guest can skip running it. Unless we do a full reset > > there's always a potential for packets to slip through, e.g. on xdp > > program changes. Maybe a flush command is needed, or force queue or > > device reset to make sure nothing is going on. Does this make sense? > > > > Thanks! > >
