On 10.01.2012, at 01:51, Scott Wood wrote: > On 01/09/2012 11:46 AM, Alexander Graf wrote: >> >> On 21.12.2011, at 02:34, Scott Wood wrote: > [...] >>> Current issues include: >>> - Machine checks from guest state are not routed to the host handler. >>> - The guest can cause a host oops by executing an emulated instruction >>> in a page that lacks read permission. Existing e500/4xx support has >>> the same problem. >> >> We solve that in book3s pr by doing >> >> LAST_INST = <known bad value>; >> PACA->kvm_mode = <recover at next inst>; >> lwz(guest pc); >> do_more_stuff(); >> >> That way when an exception occurs at lwz() the DO_KVM handler checks that we're in kvm mode "recover" which does basically srr0+=4; rfi;. > > 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? 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
