On Wed, 15 Dec 2010 00:29:40 +0100 Alexander Graf <agraf@xxxxxxx> wrote: > On 15.12.2010, at 00:17, Scott Wood wrote: > > > So that once KVM has an interrupt to deliver, and sees that critical is > > engaged, it knows that the next magic page store will resolve things. > > Either it is a store to critical, and KVM can now deliver the > > interrupt -- or it is some other store (scratch or MSR itself) and thus > > int_pending has not yet been checked. > > > > I don't think it would be a problem for live patching. It just seems a > > bit icky. > > Oh, because you'd only trap stores, but no writes? Yep, that would work. "writes" or "loads"? :-) > I actually like that idea. It's probably the cleanest we can get away with without deep modifications of the guest. Single-step is always icky. Well, there's another complication -- if we trap on the final store to end the critical section, the critical section won't actually be ended until after that instruction executes. Which won't happen until we set the page to read/write and let it go. So we'd have to look at the instruction to see what it's doing. > Thinking about the whole thing - can't we create an "interrupt notification page"? Some page that is always mapped read-only when interrupts are available, but read-write when they're not? > Then we could just do an unconditional store after the crit section is done and everyone's happy. I'd limit it to interrupts that were deferred due to critical, to avoid unnecessary MMU manipulation, and unnecessary traps when doing mtmsr/wrtee if there's an interrupt pending and old EE = new EE = zero (assuming the guest doesn't use a separate restore path for that case). But otherwise sounds reasonable, if we're willing to change the interface that much. Does it even need to be read-only, or could it be entirely unmapped when there's a pending interrupt? -Scott -- 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
