On Mon, 2012-01-23 at 13:21 -0600, Scott Wood wrote:
BTW, for non-booke, when is DEC checked when interrupts are hard-enabled
as part of exception return? Likewise with the PS3 HV thing. I only
see the iseries check in the exception path.
Exception return restores them to their previous state, so shouldn't be
a problem unless your exception takes long enough to overflow the DEC in
which case you have other problems. The PS/3 case might be broken.
Perhaps the issues with a higher priority interrupt intervening can be
addressed by messing around with current task priority at the MPIC (with
an hcall introduced for the hv case, since currently task priority is
not exposed to the guest). I haven't had time to revisit this, and
don't expect to soon. If someone else wants to try, fine. In the
meantime, lazy EE is causing problems.
Or by storing pending interrupts in an array.
I'd still like to know the answer to that last question. It's difficult
to determine how to correctly implement this stuff for our hardware if
it looks like there are holes in the scheme for hardware that this is
supposed to already work with.
Traditionally EE's have always been "level sensitive" on PowerPC,
You mean besides the places you already have to work around, such as
doorbells
Which you introduced as well... this is especially ironic since BookE
had the decrementer done right in the first place :-)
and book3s decrementers
Book3s decrementer is level sensitive based on the sign bit of the
decrementer (a bit odd but heh....) at least on 64-bit processors.
and other hypervisors...
I wouldn't take the PS3 HV and legacy iseries HV as good design
examples :-) The later was working around limited HW functionality at
the time as well.
and you force
all functions that enable interrupts to create a stack frame to deal
with this.
Right, but overall this is still more efficient performance wise on most
processors than whacking the MSR.
However the main thing is that this significantly improves the quality
of the samples obtained from performance interrupts which can now act as
pseudo-NMI up to a certain point.
It also helps with Alex PR KVM but that's just a detail really.
the way you changed that is arguably an utterly broken HW design
Just because you don't like it, and it doesn't play well with your hack,
doesn't make it "utterly broken".
Deal with it. The "hack" has been there for long enough and works well.
I don't want compile-time conditional to change that behaviour.
and I am not too keen on changing our core interrupt handling to deal with it
via
ifdef's if we can find a less invasive solution.
Wheras having to significantly change the way interrupts work because
the register size doubled is so totally reasonable...
We were very tempted at some point to do lazy EE for 32-bit as well,
eventually decided we didn't care enough :-)
What is the compelling reason for forcing lazy EE on us? Why is it tied
to 64-bit?
Because that's where we historically implemented it and because iSeries
more/less required to begin with. And I don't want to have a split
scheme, especially not a compile time one.
