On Tue, 2020-12-01 at 10:35 +0000, Stefan Hajnoczi wrote: > On Tue, Dec 01, 2020 at 12:05:04PM +0800, Jason Wang wrote: > > On 2020/11/30 下午8:47, Stefan Hajnoczi wrote: > > > 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. > > > > I see. I've considered something similar. e.g using eBPF dataplane > > in > > vhost, but it requires a lot of work. For guest RAM access, we > > probably can > > provide some eBPF helpers to do that but we need strong point to > > convince > > eBPF guys. > > > > > > > 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? > > > > Yes. > > > > > > > Wouldn't it need to write to userspace memory to store > > > the ring index that was written to the doorbell register, for > > > example? > > > > The proram itself can choose want to do: > > > > 1) do datamatch and write/wakeup eventfd > > > > or > > > > 2) transport the write via an arbitrary fd as what has been done in > > this > > proposal, but the protocol is userspace defined > > > > > How would the program communicate with userspace (eventfd isn't > > > enough) > > > and how can it handle synchronous I/O accesses like reads? > > > > I may miss something, but it can behave exactly as what has been > > proposed in > > this patch? > > I see. This seems to have two possible advantages: > 1. Pushing the kvm.ko code into userspace thanks to eBPF. Less kernel > code. > 2. Allowing more flexibile I/O dispatch logic (e.g. ioeventfd-style > datamatch) and communication protocols. > > I think #1 is minor because the communication protocol is trivial, > struct kvm_io_device can be reused for dispatch, and eBPF will > introduce > some complexity itself. > > #2 is more interesting but I'm not sure how to use this extra > flexibility to get a big advantage. Maybe vfio-user applications > could > install an eBPF program that speaks the vfio-user protocol instead of > the ioregionfd protocol, making it easier to integrate ioregionfd > into > vfio-user programs? > > My opinion is that eBPF complicates things and since we lack a strong > use case for that extra flexibility, I would stick to the ioregionfd > proposal. > I agree with this point. > Elena, Jason: Do you have any opinions on this? > > Stefan
