public inbox for [email protected]
 help / color / mirror / Atom feed
* [PATCH 0/2] eventfd: simplify signal helpers
@ 2023-07-13 10:05 Christian Brauner
  2023-07-13 17:10 ` Alex Williamson
  0 siblings, 1 reply; 9+ messages in thread
From: Christian Brauner @ 2023-07-13 10:05 UTC (permalink / raw)
  To: linux-fsdevel
  Cc: Vitaly Kuznetsov, Sean Christopherson, Paolo Bonzini,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
	David Woodhouse, Paul Durrant, Oded Gabbay, Wu Hao, Tom Rix,
	Moritz Fischer, Xu Yilun, Zhenyu Wang, Zhi Wang, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, David Airlie,
	Daniel Vetter, Leon Romanovsky, Jason Gunthorpe, Frederic Barrat,
	Andrew Donnellan, Arnd Bergmann, Greg Kroah-Hartman, Eric Farman,
	Matthew Rosato, Halil Pasic, Vineeth Vijayan, Peter Oberparleiter,
	Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
	Christian Borntraeger, Sven Schnelle, Tony Krowiak, Jason Herne,
	Harald Freudenberger, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
	Diana Craciun, Alex Williamson, Eric Auger, Fei Li,
	Benjamin LaHaise, Christian Brauner, Johannes Weiner,
	Michal Hocko, Roman Gushchin, Shakeel Butt, Muchun Song,
	Kirti Wankhede, kvm, linux-kernel, dri-devel, linux-fpga,
	intel-gvt-dev, intel-gfx, linux-rdma, linuxppc-dev, linux-s390,
	linux-usb, virtualization, netdev, linux-aio, cgroups, linux-mm,
	Jens Axboe, Pavel Begunkov, io-uring

Hey everyone,

This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
by removing the count argument which is effectively unused.

---



---
base-commit: 6be357f00aad4189130147fdc6f568cf776a4909
change-id: 20230713-vfs-eventfd-signal-0b0d167ad6ec


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
  2023-07-13 10:05 Christian Brauner
@ 2023-07-13 17:10 ` Alex Williamson
  0 siblings, 0 replies; 9+ messages in thread
From: Alex Williamson @ 2023-07-13 17:10 UTC (permalink / raw)
  To: Christian Brauner
  Cc: linux-fsdevel, linux-aio, linux-usb, Matthew Rosato, Paul Durrant,
	Tom Rix, Jason Wang, dri-devel, Michal Hocko, linux-mm,
	Kirti Wankhede, Paolo Bonzini, Jens Axboe, Vineeth Vijayan,
	Diana Craciun, Alexander Gordeev, Xuan Zhuo, Shakeel Butt,
	Vasily Gorbik, Leon Romanovsky, Harald Freudenberger, Fei Li, x86,
	Roman Gushchin, Halil Pasic, Jason Gunthorpe, Ingo Molnar,
	intel-gfx, Christian Borntraeger, linux-fpga, Zhi Wang, Wu Hao,
	Jason Herne, Eric Farman, Dave Hansen, Andrew Donnellan,
	Arnd Bergmann, linux-s390, Heiko Carstens, Johannes Weiner,
	linuxppc-dev, Eric Auger, Borislav Petkov, kvm, Rodrigo Vivi,
	cgroups, Thomas Gleixner, virtualization, intel-gvt-dev, io-uring,
	netdev, Tony Krowiak, Tvrtko Ursulin, Pavel Begunkov,
	Sean Christopherson, Oded Gabbay, Muchun Song,
	Peter Oberparleiter, linux-kernel, linux-rdma, Benjamin LaHaise,
	Michael S. Tsirkin, Sven Schnelle, Greg Kroah-Hartman,
	Frederic Barrat, Moritz Fischer, Vitaly Kuznetsov,
	David Woodhouse, Xu Yilun, jaz

On Thu, 13 Jul 2023 12:05:36 +0200
Christian Brauner <[email protected]> wrote:

> Hey everyone,
> 
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> by removing the count argument which is effectively unused.

We have a patch under review which does in fact make use of the
signaling value:

https://lore.kernel.org/all/[email protected]/

Thanks,
Alex


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
       [not found] <[email protected]>
@ 2023-07-14  7:05 ` Christian Brauner
  2023-07-14 15:24   ` Jason Gunthorpe
  2023-07-17  8:29   ` Grzegorz Jaszczyk
  0 siblings, 2 replies; 9+ messages in thread
From: Christian Brauner @ 2023-07-14  7:05 UTC (permalink / raw)
  To: Alex Williamson
  Cc: linux-fsdevel, linux-aio, linux-usb, Matthew Rosato, Paul Durrant,
	Tom Rix, Jason Wang, dri-devel, Michal Hocko, linux-mm,
	Kirti Wankhede, Paolo Bonzini, Jens Axboe, Vineeth Vijayan,
	Diana Craciun, Alexander Gordeev, Xuan Zhuo, Shakeel Butt,
	Vasily Gorbik, Leon Romanovsky, Harald Freudenberger, Fei Li, x86,
	Roman Gushchin, Halil Pasic, Jason Gunthorpe, Ingo Molnar,
	intel-gfx, Christian Borntraeger, linux-fpga, Zhi Wang, Wu Hao,
	Jason Herne, Eric Farman, Dave Hansen, Andrew Donnellan,
	Arnd Bergmann, linux-s390, Heiko Carstens, Johannes Weiner,
	linuxppc-dev, Eric Auger, Borislav Petkov, kvm, Rodrigo Vivi,
	cgroups, Thomas Gleixner, virtualization, intel-gvt-dev, io-uring,
	netdev, Tony Krowiak, Tvrtko Ursulin, Pavel Begunkov,
	Sean Christopherson, Oded Gabbay, Muchun Song,
	Peter Oberparleiter, linux-kernel, linux-rdma, Benjamin LaHaise,
	Michael S. Tsirkin, Sven Schnelle, Greg Kroah-Hartman,
	Frederic Barrat, Moritz Fischer, Vitaly Kuznetsov,
	David Woodhouse, Xu Yilun, jaz

On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote:
> On Thu, 13 Jul 2023 12:05:36 +0200
> Christian Brauner <[email protected]> wrote:
> 
> > Hey everyone,
> > 
> > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> > by removing the count argument which is effectively unused.
> 
> We have a patch under review which does in fact make use of the
> signaling value:
> 
> https://lore.kernel.org/all/[email protected]/

Huh, thanks for the link.

Quoting from
https://patchwork.kernel.org/project/kvm/patch/[email protected]/#25266856

> Reading an eventfd returns an 8-byte value, we generally only use it
> as a counter, but it's been discussed previously and IIRC, it's possible
> to use that value as a notification value.

So the goal is to pipe a specific value through eventfd? But it is
explicitly a counter. The whole thing is written around a counter and
each write and signal adds to the counter.

The consequences are pretty well described in the cover letter of
v6 https://lore.kernel.org/all/[email protected]/

> Since the eventfd counter is used as ACPI notification value
> placeholder, the eventfd signaling needs to be serialized in order to
> not end up with notification values being coalesced. Therefore ACPI
> notification values are buffered and signalized one by one, when the
> previous notification value has been consumed.

But isn't this a good indication that you really don't want an eventfd
but something that's explicitly designed to associate specific data with
a notification? Using eventfd in that manner requires serialization,
buffering, and enforces ordering.

I have no skin in the game aside from having to drop this conversion
which I'm fine to do if there are actually users for this btu really,
that looks a lot like abusing an api that really wasn't designed for
this.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
  2023-07-14  7:05 ` [PATCH 0/2] eventfd: simplify signal helpers Christian Brauner
@ 2023-07-14 15:24   ` Jason Gunthorpe
  2023-07-17  8:29   ` Grzegorz Jaszczyk
  1 sibling, 0 replies; 9+ messages in thread
From: Jason Gunthorpe @ 2023-07-14 15:24 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Alex Williamson, linux-fsdevel, linux-aio, linux-usb,
	Matthew Rosato, Paul Durrant, Tom Rix, Jason Wang, dri-devel,
	Michal Hocko, linux-mm, Kirti Wankhede, Paolo Bonzini, Jens Axboe,
	Vineeth Vijayan, Diana Craciun, Alexander Gordeev, Xuan Zhuo,
	Shakeel Butt, Vasily Gorbik, Leon Romanovsky,
	Harald Freudenberger, Fei Li, x86, Roman Gushchin, Halil Pasic,
	Ingo Molnar, intel-gfx, Christian Borntraeger, linux-fpga,
	Zhi Wang, Wu Hao, Jason Herne, Eric Farman, Dave Hansen,
	Andrew Donnellan, Arnd Bergmann, linux-s390, Heiko Carstens,
	Johannes Weiner, linuxppc-dev, Eric Auger, Borislav Petkov, kvm,
	Rodrigo Vivi, cgroups, Thomas Gleixner, virtualization,
	intel-gvt-dev, io-uring, netdev, Tony Krowiak, Tvrtko Ursulin,
	Pavel Begunkov, Sean Christopherson, Oded Gabbay, Muchun Song,
	Peter Oberparleiter, linux-kernel, linux-rdma, Benjamin LaHaise,
	Michael S. Tsirkin, Sven Schnelle, Greg Kroah-Hartman,
	Frederic Barrat, Moritz Fischer, Vitaly Kuznetsov,
	David Woodhouse, Xu Yilun, jaz

On Fri, Jul 14, 2023 at 09:05:21AM +0200, Christian Brauner wrote:

> I have no skin in the game aside from having to drop this conversion
> which I'm fine to do if there are actually users for this btu really,
> that looks a lot like abusing an api that really wasn't designed for
> this.

Yeah, I think so too. The ACPI thing should use its own FD if it wants
to feed actual data..

Jason


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
  2023-07-14  7:05 ` [PATCH 0/2] eventfd: simplify signal helpers Christian Brauner
  2023-07-14 15:24   ` Jason Gunthorpe
@ 2023-07-17  8:29   ` Grzegorz Jaszczyk
  2023-07-17 19:08     ` Alex Williamson
  1 sibling, 1 reply; 9+ messages in thread
From: Grzegorz Jaszczyk @ 2023-07-17  8:29 UTC (permalink / raw)
  To: Christian Brauner, Alex Williamson
  Cc: linux-fsdevel, linux-aio, linux-usb, Matthew Rosato, Paul Durrant,
	Tom Rix, Jason Wang, dri-devel, Michal Hocko, linux-mm,
	Kirti Wankhede, Paolo Bonzini, Jens Axboe, Vineeth Vijayan,
	Diana Craciun, Alexander Gordeev, Xuan Zhuo, Shakeel Butt,
	Vasily Gorbik, Leon Romanovsky, Harald Freudenberger, Fei Li, x86,
	Roman Gushchin, Halil Pasic, Jason Gunthorpe, Ingo Molnar,
	intel-gfx, Christian Borntraeger, linux-fpga, Zhi Wang, Wu Hao,
	Jason Herne, Eric Farman, Dave Hansen, Andrew Donnellan,
	Arnd Bergmann, linux-s390, Heiko Carstens, Johannes Weiner,
	linuxppc-dev, Eric Auger, Borislav Petkov, kvm, Rodrigo Vivi,
	cgroups, Thomas Gleixner, virtualization, intel-gvt-dev, io-uring,
	netdev, Tony Krowiak, Tvrtko Ursulin, Pavel Begunkov,
	Sean Christopherson, Oded Gabbay, Muchun Song,
	Peter Oberparleiter, linux-kernel, linux-rdma, Benjamin LaHaise,
	Michael S. Tsirkin, Sven Schnelle, Greg Kroah-Hartman,
	Frederic Barrat, Moritz Fischer, Vitaly Kuznetsov,
	David Woodhouse, Xu Yilun, Dominik Behr, Marcin Wojtas

pt., 14 lip 2023 o 09:05 Christian Brauner <[email protected]> napisał(a):
>
> On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote:
> > On Thu, 13 Jul 2023 12:05:36 +0200
> > Christian Brauner <[email protected]> wrote:
> >
> > > Hey everyone,
> > >
> > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> > > by removing the count argument which is effectively unused.
> >
> > We have a patch under review which does in fact make use of the
> > signaling value:
> >
> > https://lore.kernel.org/all/[email protected]/
>
> Huh, thanks for the link.
>
> Quoting from
> https://patchwork.kernel.org/project/kvm/patch/[email protected]/#25266856
>
> > Reading an eventfd returns an 8-byte value, we generally only use it
> > as a counter, but it's been discussed previously and IIRC, it's possible
> > to use that value as a notification value.
>
> So the goal is to pipe a specific value through eventfd? But it is
> explicitly a counter. The whole thing is written around a counter and
> each write and signal adds to the counter.
>
> The consequences are pretty well described in the cover letter of
> v6 https://lore.kernel.org/all/[email protected]/
>
> > Since the eventfd counter is used as ACPI notification value
> > placeholder, the eventfd signaling needs to be serialized in order to
> > not end up with notification values being coalesced. Therefore ACPI
> > notification values are buffered and signalized one by one, when the
> > previous notification value has been consumed.
>
> But isn't this a good indication that you really don't want an eventfd
> but something that's explicitly designed to associate specific data with
> a notification? Using eventfd in that manner requires serialization,
> buffering, and enforces ordering.
>
> I have no skin in the game aside from having to drop this conversion
> which I'm fine to do if there are actually users for this btu really,
> that looks a lot like abusing an api that really wasn't designed for
> this.

https://patchwork.kernel.org/project/kvm/patch/[email protected]/
was posted at the beginig of March and one of the main things we've
discussed was the mechanism for propagating acpi notification value.
We've endup with eventfd as the best mechanism and have actually been
using it from v2. I really do not want to waste this effort, I think
we are quite advanced with v6 now. Additionally we didn't actually
modify any part of eventfd support that was in place, we only used it
in a specific (and discussed beforehand) way.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
  2023-07-17  8:29   ` Grzegorz Jaszczyk
@ 2023-07-17 19:08     ` Alex Williamson
  2023-07-17 22:12       ` Jason Gunthorpe
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Williamson @ 2023-07-17 19:08 UTC (permalink / raw)
  To: Grzegorz Jaszczyk
  Cc: Christian Brauner, linux-fsdevel, linux-aio, linux-usb,
	Matthew Rosato, Paul Durrant, Tom Rix, Jason Wang, dri-devel,
	Michal Hocko, linux-mm, Kirti Wankhede, Paolo Bonzini, Jens Axboe,
	Vineeth Vijayan, Diana Craciun, Alexander Gordeev, Xuan Zhuo,
	Shakeel Butt, Vasily Gorbik, Leon Romanovsky,
	Harald Freudenberger, Fei Li, x86, Roman Gushchin, Halil Pasic,
	Jason Gunthorpe, Ingo Molnar, intel-gfx, Christian Borntraeger,
	linux-fpga, Zhi Wang, Wu Hao, Jason Herne, Eric Farman,
	Dave Hansen, Andrew Donnellan, Arnd Bergmann, linux-s390,
	Heiko Carstens, Johannes Weiner, linuxppc-dev, Eric Auger,
	Borislav Petkov, kvm, Rodrigo Vivi, cgroups, Thomas Gleixner,
	virtualization, intel-gvt-dev, io-uring, netdev, Tony Krowiak,
	Tvrtko Ursulin, Pavel Begunkov, Sean Christopherson, Oded Gabbay,
	Muchun Song, Peter Oberparleiter, linux-kernel, linux-rdma,
	Benjamin LaHaise, Michael S. Tsirkin, Sven Schnelle,
	Greg Kroah-Hartman, Frederic Barrat, Moritz Fischer,
	Vitaly Kuznetsov, David Woodhouse, Xu Yilun, Dominik Behr,
	Marcin Wojtas

On Mon, 17 Jul 2023 10:29:34 +0200
Grzegorz Jaszczyk <[email protected]> wrote:

> pt., 14 lip 2023 o 09:05 Christian Brauner <[email protected]> napisał(a):
> >
> > On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote:  
> > > On Thu, 13 Jul 2023 12:05:36 +0200
> > > Christian Brauner <[email protected]> wrote:
> > >  
> > > > Hey everyone,
> > > >
> > > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> > > > by removing the count argument which is effectively unused.  
> > >
> > > We have a patch under review which does in fact make use of the
> > > signaling value:
> > >
> > > https://lore.kernel.org/all/[email protected]/  
> >
> > Huh, thanks for the link.
> >
> > Quoting from
> > https://patchwork.kernel.org/project/kvm/patch/[email protected]/#25266856
> >  
> > > Reading an eventfd returns an 8-byte value, we generally only use it
> > > as a counter, but it's been discussed previously and IIRC, it's possible
> > > to use that value as a notification value.  
> >
> > So the goal is to pipe a specific value through eventfd? But it is
> > explicitly a counter. The whole thing is written around a counter and
> > each write and signal adds to the counter.
> >
> > The consequences are pretty well described in the cover letter of
> > v6 https://lore.kernel.org/all/[email protected]/
> >  
> > > Since the eventfd counter is used as ACPI notification value
> > > placeholder, the eventfd signaling needs to be serialized in order to
> > > not end up with notification values being coalesced. Therefore ACPI
> > > notification values are buffered and signalized one by one, when the
> > > previous notification value has been consumed.  
> >
> > But isn't this a good indication that you really don't want an eventfd
> > but something that's explicitly designed to associate specific data with
> > a notification? Using eventfd in that manner requires serialization,
> > buffering, and enforces ordering.

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.

As this series demonstrates, the current in-kernel users only increment
the counter and most userspace likely discards the counter value, which
makes the counter largely a waste.  While perhaps unconventional,
there's no requirement that the counter may only be incremented by one,
nor any restriction that I see in how userspace must interpret the
counter value.

As I understand the ACPI notification proposal that Grzegorz links
below, a notification with an interpreted value allows for a more
direct userspace implementation when dealing with a series of discrete
notification with value events.  Thanks,

Alex

> > I have no skin in the game aside from having to drop this conversion
> > which I'm fine to do if there are actually users for this btu really,
> > that looks a lot like abusing an api that really wasn't designed for
> > this.  
> 
> https://patchwork.kernel.org/project/kvm/patch/[email protected]/
> was posted at the beginig of March and one of the main things we've
> discussed was the mechanism for propagating acpi notification value.
> We've endup with eventfd as the best mechanism and have actually been
> using it from v2. I really do not want to waste this effort, I think
> we are quite advanced with v6 now. Additionally we didn't actually
> modify any part of eventfd support that was in place, we only used it
> in a specific (and discussed beforehand) way.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
  2023-07-17 19:08     ` Alex Williamson
@ 2023-07-17 22:12       ` Jason Gunthorpe
  2023-07-17 22:52         ` Alex Williamson
  0 siblings, 1 reply; 9+ messages in thread
From: Jason Gunthorpe @ 2023-07-17 22:12 UTC (permalink / raw)
  To: Alex Williamson
  Cc: Grzegorz Jaszczyk, Christian Brauner, linux-fsdevel, linux-aio,
	linux-usb, Matthew Rosato, Paul Durrant, Tom Rix, Jason Wang,
	dri-devel, Michal Hocko, linux-mm, Kirti Wankhede, Paolo Bonzini,
	Jens Axboe, Vineeth Vijayan, Diana Craciun, Alexander Gordeev,
	Xuan Zhuo, Shakeel Butt, Vasily Gorbik, Leon Romanovsky,
	Harald Freudenberger, Fei Li, x86, Roman Gushchin, Halil Pasic,
	Ingo Molnar, intel-gfx, Christian Borntraeger, linux-fpga,
	Zhi Wang, Wu Hao, Jason Herne, Eric Farman, Dave Hansen,
	Andrew Donnellan, Arnd Bergmann, linux-s390, Heiko Carstens,
	Johannes Weiner, linuxppc-dev, Eric Auger, Borislav Petkov, kvm,
	Rodrigo Vivi, cgroups, Thomas Gleixner, virtualization,
	intel-gvt-dev, io-uring, netdev, Tony Krowiak, Tvrtko Ursulin,
	Pavel Begunkov, Sean Christopherson, Oded Gabbay, Muchun Song,
	Peter Oberparleiter, linux-kernel, linux-rdma, Benjamin LaHaise,
	Michael S. Tsirkin, Sven Schnelle, Greg Kroah-Hartman,
	Frederic Barrat, Moritz Fischer, Vitaly Kuznetsov,
	David Woodhouse, Xu Yilun, Dominik Behr, Marcin Wojtas

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

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
  2023-07-17 22:12       ` Jason Gunthorpe
@ 2023-07-17 22:52         ` Alex Williamson
  2023-07-18 15:56           ` Jason Gunthorpe
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Williamson @ 2023-07-17 22:52 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Grzegorz Jaszczyk, Christian Brauner, linux-fsdevel, linux-aio,
	linux-usb, Matthew Rosato, Paul Durrant, Tom Rix, Jason Wang,
	dri-devel, Michal Hocko, linux-mm, Kirti Wankhede, Paolo Bonzini,
	Jens Axboe, Vineeth Vijayan, Diana Craciun, Alexander Gordeev,
	Xuan Zhuo, Shakeel Butt, Vasily Gorbik, Leon Romanovsky,
	Harald Freudenberger, Fei Li, x86, Roman Gushchin, Halil Pasic,
	Ingo Molnar, intel-gfx, Christian Borntraeger, linux-fpga,
	Zhi Wang, Wu Hao, Jason Herne, Eric Farman, Dave Hansen,
	Andrew Donnellan, Arnd Bergmann, linux-s390, Heiko Carstens,
	Johannes Weiner, linuxppc-dev, Eric Auger, Borislav Petkov, kvm,
	Rodrigo Vivi, cgroups, Thomas Gleixner, virtualization,
	intel-gvt-dev, io-uring, netdev, Tony Krowiak, Tvrtko Ursulin,
	Pavel Begunkov, Sean Christopherson, Oded Gabbay, Muchun Song,
	Peter Oberparleiter, linux-kernel, linux-rdma, Benjamin LaHaise,
	Michael S. Tsirkin, Sven Schnelle, Greg Kroah-Hartman,
	Frederic Barrat, Moritz Fischer, Vitaly Kuznetsov,
	David Woodhouse, Xu Yilun, Dominik Behr, Marcin Wojtas

On Mon, 17 Jul 2023 19:12:16 -0300
Jason Gunthorpe <[email protected]> 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.
Thanks,

Alex


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/2] eventfd: simplify signal helpers
  2023-07-17 22:52         ` Alex Williamson
@ 2023-07-18 15:56           ` Jason Gunthorpe
  0 siblings, 0 replies; 9+ messages in thread
From: Jason Gunthorpe @ 2023-07-18 15:56 UTC (permalink / raw)
  To: Alex Williamson
  Cc: Grzegorz Jaszczyk, Christian Brauner, linux-fsdevel, linux-aio,
	linux-usb, Matthew Rosato, Paul Durrant, Tom Rix, Jason Wang,
	dri-devel, Michal Hocko, linux-mm, Kirti Wankhede, Paolo Bonzini,
	Jens Axboe, Vineeth Vijayan, Diana Craciun, Alexander Gordeev,
	Xuan Zhuo, Shakeel Butt, Vasily Gorbik, Leon Romanovsky,
	Harald Freudenberger, Fei Li, x86, Roman Gushchin, Halil Pasic,
	Ingo Molnar, intel-gfx, Christian Borntraeger, linux-fpga,
	Zhi Wang, Wu Hao, Jason Herne, Eric Farman, Dave Hansen,
	Andrew Donnellan, Arnd Bergmann, linux-s390, Heiko Carstens,
	Johannes Weiner, linuxppc-dev, Eric Auger, Borislav Petkov, kvm,
	Rodrigo Vivi, cgroups, Thomas Gleixner, virtualization,
	intel-gvt-dev, io-uring, netdev, Tony Krowiak, Tvrtko Ursulin,
	Pavel Begunkov, Sean Christopherson, Oded Gabbay, Muchun Song,
	Peter Oberparleiter, linux-kernel, linux-rdma, Benjamin LaHaise,
	Michael S. Tsirkin, Sven Schnelle, Greg Kroah-Hartman,
	Frederic Barrat, Moritz Fischer, Vitaly Kuznetsov,
	David Woodhouse, Xu Yilun, Dominik Behr, Marcin Wojtas

On Mon, Jul 17, 2023 at 04:52:03PM -0600, Alex Williamson wrote:
> On Mon, 17 Jul 2023 19:12:16 -0300
> Jason Gunthorpe <[email protected]> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-07-18 15:56 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <[email protected]>
2023-07-14  7:05 ` [PATCH 0/2] eventfd: simplify signal helpers Christian Brauner
2023-07-14 15:24   ` Jason Gunthorpe
2023-07-17  8:29   ` Grzegorz Jaszczyk
2023-07-17 19:08     ` Alex Williamson
2023-07-17 22:12       ` Jason Gunthorpe
2023-07-17 22:52         ` Alex Williamson
2023-07-18 15:56           ` Jason Gunthorpe
2023-07-13 10:05 Christian Brauner
2023-07-13 17:10 ` Alex Williamson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox