Re: evtchn_do_event: handler...didn't lower ipl (Was: Re: xl or xm for xen)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 5 Dec 2013 19:27:34 +0000
    From:        David Laight <david%l8s.co.uk@localhost>
    Message-ID:  <20131205192734.GQ295%snowdrop.l8s.co.uk@localhost>

  | I'd have thought that acquiring a mutex would increase the count.
  | So a count of -1 would indicate and extra release.
  | Or does this counter have silly values?

It counts backwards - I'm no x86 machine code expert (not even knowledgeable)
but it looked to me as if it was done this way to improve performance because
of the way the arithmetic works and the tests that are actually needed.

That is, going from 0 -> 1 isn't any different, as far as testing the result
works, then going from 1 -> 2, you'd need to either test before the change
(and then remember the result of the test) or make a copy of the original
value (which is the same thing done a different way) or add a comparison
with 1 to see if that's the result.

On the other hand, going from 0 -> -1 sets the carry flag, which can be
tested, so the code trivially detects that this is the first mutex taken,
which is what it needs to know.

Since for any other purpose, the values 0 1 2 3 ... and 0 -1 -2 -3 ...
are essentially equivalent sequences, the choice made sense to me.

It makes no real difference going the other way, the zero flag lets you know
when you reach 0 whether you approach from 1 or -1.

An alternative that counts up, would have been to init the counter to -1,
and have it always be 1 less than the number of held mutexes, I think that
would have been essentially equivalent computationally, but getting people
to understand that the value is always 1 less than it actually represents
would likely be far more difficult to get people to understand than simply
counting backwards.

kre