Hi,
At 17:44 +0100 on 23 Jun (1245779059), David Knight wrote:
> I've been working on a project which is to minimize the
> overhead of page_fault when PV is in log_dirty mode. I
> wrote a function "sh_prebuild", it's very much similar
> to sh_prefetch(), the major difference between them is:
> I set the "ft" as "ft_demand_write" rather than
> "ft_prefetch" when I call l1e_propagate_from_guest().
I'm not sure that's a good idea. The point of log-dirty is that it lets
the migration tool resend only the dirtied pages, and although your
change will avoid some page faults, it will increase the number of
frames that have to be retransmitted.
Also, just setting ft_demand_write won't always do what you want: in
_sh_propagate, if the guest PTE's _PAGE_DIRTY bit isn't set it will mask
out _PAGE_RW anyway.
That said, I don't understand why your live migrations are failing,
especially not on the migration _to_ the modified Xen, since the idea
you describe should be safe.
Cheers,
Tim.
> I just want to make the faulted page and its following
> pages writable and marked as dirty after a write_protect
> page_fault. The function "sh_prebuild" is called in the
> sh_page_fault() right before sh_prefetch():
>
> ---------------sh_page_fault()-----------------
>
> if ( ( shadow_mode_log_dirty(v->domain) )
> && ( ft == ft_demand_write ) )
> sh_prebuild(.......);
>
> ..............
>
> I got problems when I migrate. The code can successfully
> migrate the domainU to another UNMODIFIED Xen. But when I
> migrate a domainU from UNMODIFIED Xen back to this MODIFIED
> Xen, the domU's clock is frozen, I use "xm console" to get
> in domU's console, but I just got about 6 TSC error messages
> and no other respond.
>
> I am using 32-bit PV domain, no-PSE.
> Does someone know any reasons? Thanks.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home