On 26.11.2012, at 22:55, Alexander Graf wrote: > > On 26.11.2012, at 22:33, Paul Mackerras wrote: > >> On Mon, Nov 26, 2012 at 02:15:16PM +0100, Alexander Graf wrote: >>> >>> On 23.11.2012, at 22:42, Paul Mackerras wrote: >>> >>>> On Fri, Nov 23, 2012 at 03:13:09PM +0100, Alexander Graf wrote: >>>>> >>>>> On 22.11.2012, at 10:25, Paul Mackerras wrote: >>>>> >>>>>> + /* Do they have an SLB shadow buffer registered? */ >>>>>> + slb = vcpu->arch.slb_shadow.pinned_addr; >>>>>> + if (!slb) >>>>>> + return; >>>>> >>>>> Mind to explain this case? What happens here? Do we leave the guest with >>>>> an empty SLB? Why would this ever happen? What happens next as soon as we >>>>> go back into the guest? >>>> >>>> Yes, we leave the guest with an empty SLB, the access gets retried and >>>> this time the guest gets an SLB miss interrupt, which it can hopefully >>>> handle using an SLB miss handler that runs entirely in real mode. >>>> This could happen for instance while the guest is in SLOF or yaboot or >>>> some other code that runs basically in real mode but occasionally >>>> turns the MMU on for some accesses, and happens to have a bug where it >>>> creates a duplicate SLB entry. >>> >>> Is this what pHyp does? Also, is this what we want? Why don't we populate >>> an #MC into the guest so it knows it did something wrong? >> >> Yes, yes and we do. Anytime we get a machine check while in the guest >> we give the guest a machine check interrupt. >> >> Ultimately we want to implement the "FWNMI" (Firmware-assisted NMI) >> thing defined in PAPR which makes the handling of system reset and >> machine check slightly nicer for the guest, but that's for later. It >> will build on top of the stuff in this patch. > > So why would the function return 1 then which means "MC is handled, forget > about it" rather than 0, which means "inject MC into the guest"?
Oh wait - 1 means "have the host handle it". Let me check up the code again. Alex-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
