On Fri, Dec 15, 2023, Vineeth Remanan Pillai wrote: > > You are basically proposing that KVM bounce-buffer data between guest and host. > > I'm saying there's no _technical_ reason to use a bounce-buffer, just do zero copy. > > > I was also meaning zero copy only. The help required from the kvm side is: > - Pass the address of the shared memory to bpf programs/scheduler once > the guest sets it up. > - Invoke scheduler registered callbacks on events like VMEXIT, > VEMENTRY, interrupt injection etc. Its the job of guest and host > paravirt scheduler to interpret the shared memory contents and take > actions. > > I admit current RFC doesn't strictly implement hooks and callbacks - > it calls sched_setscheduler in place of all callbacks that I mentioned > above. I guess this was your strongest objection. Ya, more or less. > As you mentioned in the reply to Joel, if it is fine for kvm to allow > hooks into events (VMEXIT, VMENTRY, interrupt injection etc) then, it > makes it easier to develop the ABI I was mentioning and have the hooks > implemented by a paravirt scheduler. We shall re-design the > architecture based on this for v2. Instead of going straight to a full blown re-design, can you instead post slightly more incremental RFCs? E.g. flesh out enough code to get a BPF program attached and receiving information, but do NOT wait until you have fully working setup before posting the next RFC. There are essentially four-ish things to sort out: 1. Where to insert/modify hooks in KVM 2. How KVM exposes KVM-internal information through said hooks 3. How a BPF program can influence the host scheduler 4. The guest/host ABI #1 and #2 are largely KVM-only, and I think/hope we can get a rough idea of how to address them before moving onto #3 and #4 (assuming #3 isn't already a solved problem).
