All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [PATCH V3] X86/vMCE: handle broken page with regard to migration
Date: Wed, 21 Nov 2012 11:18:44 +0000	[thread overview]
Message-ID: <50ACB894.1070509@eu.citrix.com> (raw)
In-Reply-To: <1353496027.13542.119.camel@zakaz.uk.xensource.com>

On 21/11/12 11:07, Ian Campbell wrote:
> On Tue, 2012-11-20 at 18:54 +0000, Liu, Jinsong wrote:
>> Well, let me elaborate more my thought about broken page occur at last iter:
>>
>> Theoretically we can separate 'broken page at last iter' into several sub-cases, and optimize case by case:
>> 1. if the page (which will break at last iter) is not on dirty bitmap (of last iter) --> do nothing is OK, target will happily run w/o broken page;
>> 2. if the page (which will break at last iter) is on dirty bitmap (of last iter)
>>    2.1 if at last iter, vmce occur after page copy --> do nothing is OK, target happily run w/o broken page;
>>    2.2 if vmce occur beofre pfn_type transfer --> do nothing is OK, V2 patch has correctly handle the case, target will set p2m broken correctly;
>>    2.3 if vmce occur after pfn_type transfer and before copy page to target --> we need handle this case;
>>
>> Practically considering it's rare enough, and code complication, we handle it in a simple way (not so optimized but enough for real life):
>> - we don't distinguish if the page is in dirty bitmap of last iter;
>> - we don't prefer adding new hypercall for this corner case, instead we'd like to re-use currently existed hypercall;
>> - if vmce occur at last iter, we do 1~2 more iter.
> Can't a page break on each "last" iter. i.e. you might actually go
> around as many times as there are pages in the last batch?

I think it would be only if the pages break one by one, at just the 
right time -- that seems pretty unlikely. :-)

  -George

  reply	other threads:[~2012-11-21 11:18 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 [this message]
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
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=50ACB894.1070509@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.