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. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
