Re: [RFC] /dev/ioasid uAPI proposal
From: Jason Wang
Date: Fri Jun 11 2021 - 01:44:44 EST
在 2021/6/10 下午7:47, Jason Gunthorpe 写道:
On Thu, Jun 10, 2021 at 10:00:01AM +0800, Jason Wang wrote:
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already worked
for multifds.
How so? io_uring is about sending work to the kernel, not getting
structued events back?
Actually it can. Userspace can poll multiple fds via preparing multiple sqes
with IORING_OP_ADD flag.
Poll is only a part of what is needed here, the main issue is
transfering the PRI events to userspace quickly.
Do we really care e.g at most one more syscall in this case? I think the
time spent on demand paging is much more than transferring #PF to
userspace. What's more, a well designed vIOMMU capable IOMMU hardware
should have the ability to inject such event directly to guest if #PF
happens on L1.
This means another ring and we need introduce ioctl() to add or remove
ioasids from the poll. And it still need a kind of fallback like a list if
the ring is full.
The max size of the ring should be determinable based on the PRI
concurrance of each device and the number of devices sharing the ring
This has at least one assumption, #PF event is the only event for the
ring, I'm not sure this is the case.
Thanks
In any event, I'm not entirely convinced eliding the PRI user/kernel
copy is the main issue here.. If we want this to be low latency I
think it ends up with some kernel driver component assisting the
vIOMMU emulation and avoiding the round trip to userspace
Jason