On 15.12.2010, at 00:17, Scott Wood wrote: > On Wed, 15 Dec 2010 00:00:08 +0100 > Alexander Graf <agraf@xxxxxxx> wrote: > >> >> On 14.12.2010, at 21:04, Scott Wood wrote: >> >>> Well, the TLB path might not be so bad if it can reuse an existing >>> check for mapping the magic page in the first place -- but if an >>> interrupt happens immediately after setting critical, but before saving >>> scratch registers, the critical end will not be the next magic page >>> write. So you'd still have to either single-step or emulate the stores >>> at least. >> >> We could also move the critical value to its own page, so we only have to trap that one :). > > Stable ABI... > >>> Or I suppose we could document that all magic page stores other than >>> ending critical must come before checking int_pending, though that seems >>> a bit ugly. >> >> That one's very hard to do with live binary patching > > Sorry, I was only talking about stores within a critical section -- not > unrelated stores that other patched instructions might do. > > 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. The hard part here is that currently the ppc kvm emulator treats every memory write trap as mmio. But that's changeable. 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. 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. 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
