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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
