On 15.02.2012, at 20:40, Scott Wood wrote: > On 02/15/2012 01:36 PM, Alexander Graf wrote: >> >> On 10.01.2012, at 01:51, Scott Wood wrote: >>> I was thinking we'd check ESR[EPID] or SRR1[IS] as appropriate, and >>> treat it as a kernel fault (search exception table) -- but this works >>> too and is a bit cleaner (could be other uses of external pid), at the >>> expense of a couple extra instructions in the emulation path (but >>> probably a slightly faster host TLB handler). >>> >>> The check wouldn't go in DO_KVM, though, since on bookehv that only >>> deals with diverting flow when xSRR1[GS] is set, which wouldn't be the >>> case here. >> >> Thinking about it a bit more, how is this different from a failed get_user()? We can just use the same fixup mechanism as there, right? > > The fixup mechanism can be the same (we'd like to know whether it failed > due to TLB miss or DSI, so we know which to reflect No, we only want to know "fast path failed". The reason is a different pair of shoes and should be evaluated in the slow path. We shouldn't ever fault here during normal operation btw. We already executed a guest instruction, so there's almost no reason it can't be read. > -- but if necessary > I think we can figure that out with a tlbsx). What's different is that > the page fault handler needs to know that any external pid (or AS1) > fault is bad, same as if the address were in the kernel area, and it > should go directly to searching the exception tables instead of trying > to page something in. Yes and no. We need to force it to search the exception tables. We don't care if the page fault handlers knows anything about external pids. Either way, we discussed the further stuff on IRC and came to a working solution :). Stay tuned. Alex -- 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
