On 14.12.2010, at 21:04, Scott Wood wrote: > On Tue, 14 Dec 2010 12:37:32 -0600 > Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: > >> On Tue, 14 Dec 2010 18:48:18 +0100 >> Alexander Graf <agraf@xxxxxxx> wrote: >> >>> The critical section is to prevent us from overwriting the scratch >>> registers, yeah. And I think you're right - I had a thinko last night. >>> >>> If we see that we should inject an interrupt, but we're inside of a >>> critical section, we could set the magic page to r/o and try to find the >>> critical end at which point we can just inject. >> >> Yeah, I thought of that as well -- but single stepping seemed better >> than messing with MMU code (one less thing to check for on the TLB miss >> path), and it shouldn't happen often enough, or for enough instructions, >> to be a performance issue. > > 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 :). > 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 and we've seen the mess that pv-ops brought to the x86 world (it's disabled for bare metal on sles due to performance penalties). 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
