On Mon, Jul 17, 2023 at 04:52:03PM -0600, Alex Williamson wrote: > On Mon, 17 Jul 2023 19:12:16 -0300 > Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > On Mon, Jul 17, 2023 at 01:08:31PM -0600, Alex Williamson wrote: > > > > > What would that mechanism be? We've been iterating on getting the > > > serialization and buffering correct, but I don't know of another means > > > that combines the notification with a value, so we'd likely end up with > > > an eventfd only for notification and a separate ring buffer for > > > notification values. > > > > All FDs do this. You just have to make a FD with custom > > file_operations that does what this wants. The uAPI shouldn't be able > > to tell if the FD is backing it with an eventfd or otherwise. Have the > > kernel return the FD instead of accepting it. Follow the basic design > > of eg mlx5vf_save_fops > > Sure, userspace could poll on any fd and read a value from it, but at > that point we're essentially duplicating a lot of what eventfd provides > for a minor(?) semantic difference over how the counter value is > interpreted. Using an actual eventfd allows the ACPI notification to > work as just another interrupt index within the existing vfio IRQ > uAPI. Yes, duplicated, sort of, whatever the "ack" is to allow pushing a new value can be revised to run as part of the read. But I don't really view it as a minor difference. eventfd is a counter. It should not be abused otherwise, even if it can be made to work. It really isn't an IRQ if it is pushing an async message w/data. Jason
