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

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

George Dunlap wrote:
> On 19/11/12 16:57, Ian Campbell wrote:
>> On Mon, 2012-11-19 at 15:29 +0000, George Dunlap wrote:
>>> On 19/11/12 09:55, Ian Campbell wrote:
>>>> If we get to this stage then haven't we either already sent
>>>> something over the wire for this page or marked it as dirty when
>>>> we tried and failed to send it? 
>>>> 
>>>> In the former case we don't care that the page is now broken on the
>>>> source since the target has got a good pre-breakage copy.
>>>> 
>>>> In the latter case could we not set a flag at the same time as we
>>>> mark the page dirty which means "go round at least one more time"?
>>> Yeah -- on the last iteration, the VM itself has to be paused; if
>>> any pages get broken after that, it doesn't really matter, does it?
>>> The real thing is to have a consistent "snapshot" of behavior.
>>> 
>>> I guess the one potentially tricky case to worry about is whether to
>>> deliver an MCE to the guest on restore.  Consider the following
>>> scenario: 
>>> 
>>> - Page A is modified (and marked dirty)
>>> - VM paused for last iteration
>>> - Page breaks, is marked broken in the p2m
>>> - Save code sends page A
>>> 
>>> In that case, the save code would send a "broken" page, and the
>>> restore code would mark a page as broken, and we *would* want to
>>> deliver an MCE on the far side.  But suppose the last two steps
>>> were reversed: 
>>> 
>>> - Page A modified
>>> - VM paused for last iteration
>>> - Save code sends page A
>>> - Page breaks, marked broken in the p2m
>>> 
>>> In that case, when the save code sends page A, it will send a good
>>> page; there's no need to mark it broken, or to send the guest an
>>> MCE. 
>> I guess you'd want to err on the side of stopping using a good page,
>> as opposed to continuing to use a bad page? i.e. its better to take a
>> spurious vMCE than to not take an actual one.
> 
> While that's true, taking a spurious MCE means at very least one less
> page available to the guest to use (for HVM guests that haven't
> ballooned down, at least), and the unnecessary loss of the data in
> that page.
> 
> The problem I guess is that the save code at the moment has no way of
> distinguishing the following cases:
> 1. Marked broken after the last time I sent it, but before the VM was
> paused; but the page hasn't been written to
> 2. Marked broken after the VM was paused; page hadn't been written to
> 3. Marked broken after the VM was paused, but the page had been
> written to 
> 
> In case 1, we definitely need to send a broken page; but the VM may
> have already received a vMCE.  In case 2, we don't need to send a
> broken page or a vMCE, while in #3 we need to do both.
> 

Yes, and for case 3, strictly it still has chance not to send broken page to 
target (and target will happily runs on 'good' pfn_type and 'good' page), but 
too complicated to distinguish.

> On the other hand, the whole situation is hopefully rare enough that
> maybe we can just do the simple correct thing, even if it's a tiny bit
> sub-optimal.  In that case, assuming that spurious vMCEs aren't a
> problem (e.g., #1), I think we basically just need to see if the last
> iteration contains a broken page, and if so, send the guest a vMCE on
> resume.
> 
> Thoughts?

Yes, that's exactly V3 patch did.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel