On 12.11.2009, at 11:53, Benjamin Herrenschmidt wrote:
Hum, that would defer DEC interrupts to "the next exit". So if your
guest is sitting in a spin lock for example, it wouldn't get a DEC
because it doesn't exit from the guest context to actually check if
TARGET_DEC < TB.
Ah no, you still set a target..
I think the only really good way of doing this is to use the hrtimer
to trigger the interrupt, not clear the interrupt injection bit, but
only clear it on mtdec.
That way we get the interrupt to actually interrupt the guest
context,
but instantly trigger the DEC in the guest when it sets IF=1.
I think I had a define for an "alternative" DEC method in book3s.c,
that basically checks mfdec() against 0 on every exit. Feel free to
try out of that one helps :-).
I saw that. My idea was more low-level:
- Guest set DEC, you calculate & cache target
- On exit to guest, you check target against TB, if passed, then a DEC
interrupt is pending for guest. If EE is set, you "deliver" it.
- If not passed, the substraction give you a DEC value (time to next
DEC expected by guest). You set the DEC to min(DEC,value), ie, you
make it fire the soonest of the guest DEC target vs. linux host
guest
target. Linux can cope just fine with spurrious DEC interrupts btw.
You have to do some modulo 32 bit etc... but basically, it should work
and it sounds simpler to me and will avoid the churn with timers
etc...
Oh you mean it will basically avoid us firing off a timer for mtdec 1?
So the only really novel thing I see here is that small mtdecs don't
require a timer but instead the timer only gets issued on the next
exit. I'm not sure that's a good idea though :-/. It'd probably be
better to just define a minimum threshold.
on mtdec:
if (reg < 5)
fire_off_dec();
else
fire_dec_on(reg);
Something like that.
I don't want to depend on the host DEC being the clocksource btw. So
anything munching guest and host DEC together (like pHyp does) sounds
like bad design to me. Let's better have hrtimers handle the case
where we don't need a real interrupt.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
