From: Alex Williamson <alex.williamson@redhat.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Abhishek Sahu <abhsahu@nvidia.com>,
Cornelia Huck <cohuck@redhat.com>,
Yishai Hadas <yishaih@nvidia.com>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
Kevin Tian <kevin.tian@intel.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Max Gurtovoy <mgurtovoy@nvidia.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-pm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 1/5] vfio: Add the device features for the low power entry and exit
Date: Tue, 2 Aug 2022 10:57:55 -0600 [thread overview]
Message-ID: <20220802105755.2ee80696.alex.williamson@redhat.com> (raw)
In-Reply-To: <YulSOK+YKjV2634b@nvidia.com>
On Tue, 2 Aug 2022 13:35:04 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Tue, Aug 02, 2022 at 09:41:28AM -0600, Alex Williamson wrote:
>
> > The subtlety is that there's a flag and a field and the flag can only
> > be set if the field is set, the flag can only be clear if the field is
> > clear, so we return -EINVAL for the other cases? Why do we have both a
> > flag and a field? This isn't like we're adding a feature later and the
> > flag needs to indicate that the field is present and valid. It's just
> > not a very clean interface, imo. Thanks,
>
> That isn't how I read Abhishek's proposal.. The eventfd should always
> work and should always behave as described "The notification through
> the provided eventfd will be generated only when the device has
> entered and is resumed from a low power state"
>
> If userspace provides it without LOW_POWER_REENTERY_DISABLE then it
> still generates the events.
>
> The linkage to LOW_POWER_REENTERY_DISABLE is only that userspace
> probably needs to use both elements together to generate the
> auto-reentry behavior. Kernel should not enforce it.
>
> Two fields, orthogonal behaviors.
What's the point of notifying userspace that the device was resumed if
it might already be suspended again by the time userspace responds to
the eventfd? This really muddies the single-shot vs re-entrant
behavior. If userspace allows the kernel to re-enter low power, then
they don't need to be notified on every wake. If userspace wants to be
notified on wake, userspace can also re-initiate low power entry.
Thanks,
Alex
next prev parent reply other threads:[~2022-08-02 16:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 12:15 [PATCH v5 0/5] vfio/pci: power management changes Abhishek Sahu
2022-07-19 12:15 ` [PATCH v5 1/5] vfio: Add the device features for the low power entry and exit Abhishek Sahu
2022-07-21 22:34 ` Alex Williamson
2022-07-25 14:40 ` Abhishek Sahu
2022-07-25 22:09 ` Alex Williamson
2022-07-26 12:47 ` Abhishek Sahu
2022-07-26 13:13 ` Cornelia Huck
2022-07-26 14:17 ` Alex Williamson
2022-07-26 17:23 ` Jason Gunthorpe
2022-07-27 6:07 ` Abhishek Sahu
2022-08-01 18:42 ` Alex Williamson
2022-08-02 14:04 ` Jason Gunthorpe
2022-08-02 15:41 ` Alex Williamson
2022-08-02 16:35 ` Jason Gunthorpe
2022-08-02 16:57 ` Alex Williamson [this message]
2022-08-02 17:01 ` Jason Gunthorpe
2022-08-03 6:32 ` Abhishek Sahu
2022-07-19 12:15 ` [PATCH v5 2/5] vfio: Increment the runtime PM usage count during IOCTL call Abhishek Sahu
2022-07-21 22:34 ` Alex Williamson
2022-07-19 12:15 ` [PATCH v5 3/5] vfio/pci: Mask INTx during runtime suspend Abhishek Sahu
2022-07-19 12:15 ` [PATCH v5 4/5] vfio/pci: Implement VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY/EXIT Abhishek Sahu
2022-07-21 22:34 ` Alex Williamson
2022-07-25 14:48 ` Abhishek Sahu
2022-07-19 12:15 ` [PATCH v5 5/5] vfio/pci: Implement VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY_WITH_WAKEUP Abhishek Sahu
2022-07-21 22:34 ` Alex Williamson
2022-07-25 15:04 ` Abhishek Sahu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220802105755.2ee80696.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=abhsahu@nvidia.com \
--cc=bhelgaas@google.com \
--cc=cohuck@redhat.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgurtovoy@nvidia.com \
--cc=rafael@kernel.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).