On Mon, Nov 30, 2020 at 10:14:15AM +0800, Jason Wang wrote: > On 2020/11/27 下午9:44, Stefan Hajnoczi wrote: > > On Fri, Nov 27, 2020 at 11:39:23AM +0800, Jason Wang wrote: > > > On 2020/11/26 下午8:36, Stefan Hajnoczi wrote: > > > > On Thu, Nov 26, 2020 at 11:37:30AM +0800, Jason Wang wrote: > > > > > On 2020/11/26 上午3:21, Elena Afanasova wrote: > > > Or I wonder whether we can attach an eBPF program when trapping MMIO/PIO and > > > allow it to decide how to proceed? > > The eBPF program approach is interesting, but it would probably require > > access to guest RAM and additional userspace state (e.g. device-specific > > register values). I don't know the current status of Linux eBPF - is it > > possible to access user memory (it could be swapped out)? > > > AFAIK it doesn't, but just to make sure I understand, any reason that eBPF > need to access userspace memory here? Maybe we're thinking of different things. In the past I've thought about using eBPF to avoid a trip to userspace for request submission and completion, but that requires virtqueue parsing from eBPF and guest RAM access. Are you thinking about replacing ioctl(KVM_SET_IOREGION) and all the necessary kvm.ko code with an ioctl(KVM_SET_IO_PROGRAM), where userspace can load an eBPF program into kvm.ko that gets executed when an MMIO/PIO accesses occur? Wouldn't it need to write to userspace memory to store the ring index that was written to the doorbell register, for example? How would the program communicate with userspace (eventfd isn't enough) and how can it handle synchronous I/O accesses like reads? Stefan
Attachment:
signature.asc
Description: PGP signature
