From: George Dunlap <george.dunlap@eu.citrix.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH V3] X86/vMCE: handle broken page with regard to migration
Date: Wed, 21 Nov 2012 13:59:57 +0000 [thread overview]
Message-ID: <50ACDE5D.302@eu.citrix.com> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353944A2@SHSMSX101.ccr.corp.intel.com>
On 21/11/12 13:26, Liu, Jinsong wrote:
> Ian Campbell wrote:
>> On Wed, 2012-11-21 at 11:34 +0000, George Dunlap wrote:
>>> On 20/11/12 18:42, Ian Jackson wrote:
>>>> Liu, Jinsong writes ("RE: [Xen-devel] [PATCH V3] X86/vMCE: handle
>>>> broken page with regard to migration"):
>>>>> Ian Jackson wrote:
>>>>>> Liu, Jinsong writes ("RE: [Xen-devel] [PATCH V3] X86/vMCE: handle
>>>>>> broken page with regard to migration"):
>>>>>>> No, at last lter, there are 4 points:
>>>>>>> 1. start last iter
>>>>>>> 2. get and transfer pfn_type to target
>>>>>>> 3. copy page to target
>>>>>>> 4. end last iter
>>>> ...
>>>>> It indeed checks mce after point 3 for each page, but what's the
>>>>> advantage of keeping a separate list?
>>>> It avoids yet another loop over all the pages. Unless I have
>>>> misunderstood. Which I may have, because: if it checks for mce
>>>> after
>>>> point 3 then surely that is sufficient ? We don't need to worry
>>>> about
>>>> mces after that check.
>>> It's sufficient, but wouldn't each check require a separate
>>> hypercall? That would surely be slower than just a single hypercall
>>> and a loop (which is what Jinsong's patch does).
>>>
>>> We don't actually need a list -- I think we just need to know, "Have
>>> any pages broken between reading the p2m table (
>>> xc_get_pfn_type_batch() ); if so, we do another full iteration.
>> If a page fails between 2. and 3. above then what happens at point 3?
>> I presume we can't map and send the page (since it is broken), do we
>> get some sort of failure to map?
>>
>> What happens if the failure occurs during stage 3, i.e. while the page
>> is mapped and we are reading from it?
>>
>> Ian.
> If read a broken page, it generates more serious error (say, SRAR error).
> I don't think guest has good opportunity to survive under this case --> most probably it kill itself and of course we don't need care migration now.
> However, if guest can luckly survive (say complete broken page copying to target), it's OK to continue --> its broken pfn_type will transfer to target next iter so guest will kill itself if access then.
But in this case, I'm asking what happens if the migration code reads
the page. If reading the page in the migration code causes dom0 to
crash, then the whole "last iteration" stuff is fairly pointless. :-)
-George
next prev parent reply other threads:[~2012-11-21 13:59 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-17 2:04 [PATCH V3] X86/vMCE: handle broken page with regard to migration Liu Jinsong
2012-11-16 18:19 ` Ian Jackson
2012-11-16 18:31 ` Liu, Jinsong
2012-11-19 9:55 ` Ian Campbell
2012-11-19 15:29 ` George Dunlap
2012-11-19 16:57 ` Ian Campbell
2012-11-20 15:08 ` George Dunlap
2012-11-20 17:08 ` Liu, Jinsong
2012-11-20 17:23 ` George Dunlap
2012-11-20 17:49 ` Liu, Jinsong
2012-11-20 18:54 ` Liu, Jinsong
2012-11-21 11:07 ` Ian Campbell
2012-11-21 11:18 ` George Dunlap
2012-11-21 12:11 ` Liu, Jinsong
2012-11-20 16:43 ` Liu, Jinsong
2012-11-20 16:29 ` Liu, Jinsong
2012-11-20 16:11 ` Liu, Jinsong
2012-11-20 17:48 ` George Dunlap
2012-11-20 18:13 ` Liu, Jinsong
2012-11-20 18:21 ` Ian Jackson
2012-11-20 18:39 ` Liu, Jinsong
2012-11-20 18:42 ` Ian Jackson
2012-11-20 19:07 ` Liu, Jinsong
2012-11-21 11:34 ` George Dunlap
2012-11-21 11:55 ` Ian Jackson
2012-11-21 12:11 ` Ian Campbell
2012-11-21 12:15 ` George Dunlap
2012-11-21 13:26 ` Liu, Jinsong
2012-11-21 13:37 ` Jan Beulich
2012-11-22 11:23 ` Liu, Jinsong
2012-11-21 13:59 ` George Dunlap [this message]
2012-11-22 11:44 ` Liu, Jinsong
2012-11-21 12:17 ` George Dunlap
2012-11-21 13:31 ` Liu, Jinsong
2012-11-22 12:37 ` Liu, Jinsong
2012-11-22 13:36 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50ACDE5D.302@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=jinsong.liu@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.