On May 27, 2011, at 9:07 PM, Segher Boessenkool wrote: >>>> If HDEC expires when interrupts are off, the HDEC interrupt stays >>>> pending until interrupts get re-enabled. I'm not sure exactly what >>>> the conditions are that cause an HDEC interrupt to get lost, but they >>>> seem to involve at least a partition switch. >>> >>> On some CPUs, if the top bit of the decrementer is 0 again when you re-enable >>> the interrupt, the interrupt is lost (so it is actually level-triggered). >>> The arch books talk a bit about this AFAIR. >> >> Sure, but that shouldn't happen with HDEC during the odd 50 instructions that it takes to enter the guest :) > > It's more like 500 insns, including some ptesync, so lots of cycles too. I don't think its actually that bad. IIRC the problem is mostly due to another interrupt of a higher priority that sets MSR[HV] is pending. This could also be a synchronous instruction on or near the HSRR0 (like a hypercall). Since almost everything _is_ of a higher priority, externals, VRMA-ish, emulation, that will occur first (or at the same time). This extends the window where the HDEC could go +ve. Another way around this is to check, on HV switch, if the HDEC is ever bigger then it should _ever_ be, but what paulus has in his code is actually best, although the value (10?) may be too small. > Can another hardware thread be running at the same time? I'll leave this question to someone else. -JX > > > Segher > > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
