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?
Thanks
Stefan
