[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V4] X86/vMCE: handle broken page with regard to migration
George Dunlap wrote: > On 05/12/12 15:57, Liu, Jinsong wrote: >> More simply, we can remove not only step #8 for last iteration >> check, but also the action to 'mark broken page to dirty bitmap': >> In any iteration, there is a key point #4, if vmce occur before #4 >> it will transfer proper pfn_type/pfn_number and (xl migration) will >> not access broken page (if guest access the broken page again it >> will be killed by hypervisor), if vmce occur after #4 system will >> crash and no need care migration any more. >> >> So we can go back to the original patch which used to handle 'vmce >> occur before migration' and entirely don't need add specific code to >> handle 'vmce occur during migration', since it in fact has handled >> both cases (and simple). Thoughts? > > I thought part of the point of that was to have a consistent behavior > from the presented virtual hardware -- i.e,. if the guest OS receives > a vMCE, and subsequently touches that page, it should get an SRAR? Is > that important or not? > > -George Currently hypervisor will kill guest under such case (instead of inject SRAR to guest). The reason is, not all h/w platform support SRAR so if guest access broken page it hardwarely will trigger more serious error: in some old platform which not support SRAR it will crash whole system. So to prevent this bad situation hypervisor prefer kill the guest. (Under MCA architecture, there is no cpuid to distinguish if the platform support SRAR or not --> if MCi_status report an known type indicate a SRAR it means h/w support SRAR, otherwise h/w will report an unknown error --> hypervisor then kill system under this case) So from guest point of view, it will not feel strange: if it received a vMCE (SRAO) then it access the page again, it was killed thinking itself runs at a platform not support SRAR. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |