Message-ID: <20230717165203.4ee6b1e6.alex.williamson@redhat.com>
Date: Mon, 17 Jul 2023 16:52:03 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Grzegorz Jaszczyk <jaz@...ihalf.com>, Christian Brauner
 <brauner@...nel.org>, linux-fsdevel@...r.kernel.org, linux-aio@...ck.org,
 linux-usb@...r.kernel.org, Matthew Rosato <mjrosato@...ux.ibm.com>, Paul
 Durrant <paul@....org>, Tom Rix <trix@...hat.com>, Jason Wang
 <jasowang@...hat.com>, dri-devel@...ts.freedesktop.org, Michal Hocko
 <mhocko@...nel.org>, linux-mm@...ck.org, Kirti Wankhede
 <kwankhede@...dia.com>, Paolo Bonzini <pbonzini@...hat.com>, Jens Axboe
 <axboe@...nel.dk>, Vineeth Vijayan <vneethv@...ux.ibm.com>, Diana Craciun
 <diana.craciun@....nxp.com>, Alexander Gordeev <agordeev@...ux.ibm.com>,
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Shakeel Butt <shakeelb@...gle.com>,
 Vasily Gorbik <gor@...ux.ibm.com>, Leon Romanovsky <leon@...nel.org>,
 Harald Freudenberger <freude@...ux.ibm.com>, Fei Li <fei1.li@...el.com>,
 x86@...nel.org, Roman Gushchin <roman.gushchin@...ux.dev>, Halil Pasic
 <pasic@...ux.ibm.com>, Ingo Molnar <mingo@...hat.com>,
 intel-gfx@...ts.freedesktop.org, Christian Borntraeger
 <borntraeger@...ux.ibm.com>, linux-fpga@...r.kernel.org, Zhi Wang
 <zhi.a.wang@...el.com>, Wu Hao <hao.wu@...el.com>, Jason Herne
 <jjherne@...ux.ibm.com>, Eric Farman <farman@...ux.ibm.com>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Andrew Donnellan <ajd@...ux.ibm.com>, Arnd
 Bergmann <arnd@...db.de>, linux-s390@...r.kernel.org, Heiko Carstens
 <hca@...ux.ibm.com>, Johannes Weiner <hannes@...xchg.org>,
 linuxppc-dev@...ts.ozlabs.org, Eric Auger <eric.auger@...hat.com>, Borislav
 Petkov <bp@...en8.de>, kvm@...r.kernel.org, Rodrigo Vivi
 <rodrigo.vivi@...el.com>, cgroups@...r.kernel.org, Thomas Gleixner
 <tglx@...utronix.de>, virtualization@...ts.linux-foundation.org,
 intel-gvt-dev@...ts.freedesktop.org, io-uring@...r.kernel.org,
 netdev@...r.kernel.org, Tony Krowiak <akrowiak@...ux.ibm.com>, Tvrtko
 Ursulin <tvrtko.ursulin@...ux.intel.com>, Pavel Begunkov
 <asml.silence@...il.com>, Sean Christopherson <seanjc@...gle.com>, Oded
 Gabbay <ogabbay@...nel.org>, Muchun Song <muchun.song@...ux.dev>, Peter
 Oberparleiter <oberpar@...ux.ibm.com>, linux-kernel@...r.kernel.org,
 linux-rdma@...r.kernel.org, Benjamin LaHaise <bcrl@...ck.org>, "Michael S.
 Tsirkin" <mst@...hat.com>, Sven Schnelle <svens@...ux.ibm.com>, Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>, Frederic Barrat
 <fbarrat@...ux.ibm.com>, Moritz Fischer <mdf@...nel.org>, Vitaly Kuznetsov
 <vkuznets@...hat.com>, David Woodhouse <dwmw2@...radead.org>, Xu Yilun
 <yilun.xu@...el.com>, Dominik Behr <dbehr@...omium.org>, Marcin Wojtas
 <mw@...ihalf.com>
Subject: Re: [PATCH 0/2] eventfd: simplify signal helpers

On Mon, 17 Jul 2023 19:12:16 -0300
Jason Gunthorpe <jgg@...pe.ca> 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

Powered by blists - more mailing lists