Messages in this thread | | | Subject | Re: [RFC] /dev/ioasid uAPI proposal | From | Jason Wang <> | Date | Fri, 11 Jun 2021 13:43:59 +0800 |
| |
在 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 >
| |