Re: [Xen-devel] [PATCH V4] X86/vMCE: handle broken page with regard to migration

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

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