[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/8] hvf: Move common code out
From: |
Roman Bolshakov |
Subject: |
Re: [PATCH 2/8] hvf: Move common code out |
Date: |
Fri, 4 Dec 2020 02:04:07 +0300 |
On Thu, Dec 03, 2020 at 11:13:35PM +0100, Alexander Graf wrote:
>
> On 03.12.20 19:42, Peter Collingbourne wrote:
> > On Thu, Dec 3, 2020 at 1:41 AM Roman Bolshakov <r.bolshakov@yadro.com>
> > wrote:
> > > On Mon, Nov 30, 2020 at 04:00:11PM -0800, Peter Collingbourne wrote:
> > > > What I observe is that when returning from a pending signal pselect
> > > > consumes the signal (which is also consistent with my understanding of
> > > > what pselect does). That means that it doesn't matter if we take a
> > > > second WFx exit because once we reach the pselect in the second WFx
> > > > exit the signal will have been consumed by the pselect in the first
> > > > exit and we will just wait for the next one.
> > > >
> > > Aha! Thanks for the explanation. So, the first WFI in the series of
> > > guest WFIs will likely wake up immediately? After a period without WFIs
> > > there must be a pending SIG_IPI...
> > >
> > > It shouldn't be a critical issue though because (as defined in D1.16.2)
> > > "the architecture permits a PE to leave the low-power state for any
> > > reason, it is permissible for a PE to treat WFI as a NOP, but this is
> > > not recommended for lowest power operation."
> > >
> > > BTW. I think a bit from the thread should go into the description of
> > > patch 8, because it's not trivial and it would really be helpful to keep
> > > in repo history. At least something like this (taken from an earlier
> > > reply in the thread):
> > >
> > > In this implementation IPI is blocked on the CPU thread at startup and
> > > pselect() is used to atomically unblock the signal and begin sleeping.
> > > The signal is sent unconditionally so there's no need to worry about
> > > races between actually sleeping and the "we think we're sleeping"
> > > state. It may lead to an extra wakeup but that's better than missing
> > > it entirely.
> > Okay, I'll add something like that to the next version of the patch I send
> > out.
>
>
> If this is the only change, I've already added it for v4. If you want me to
> change it further, just let me know what to replace the patch description
> with.
>
>
Thanks, Alex.
I'm fine with the description and all set.
-Roman