[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH V3] X86/vMCE: handle broken page with regard to migration
On 21/11/12 12:11, 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?
At that point the pages are already mapped. The order is:
1. From dirty bitmap / whatever, get a batch of pfns to map
2. Map them with foreign_batch
3. Read the p2m table
4. Send a list of PFNs (this is where it will list the broken ones)
5. Send all the data from those pfns
So JS is adding:
6. Read the p2m table again to see if anything has broken between 3 and
the end of 5
What happens if the failure occurs during stage 3, i.e. while the page
is mapped and we are reading from it?
I was rather wondering the same thing. :-)
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
