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"? 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
