Hi,
I had few questions regarding the mechanism employed by the hypervisor for
figuring out the pages modified during a pre-copy round of a migration of a
VM. Please assume that a migration of a VM is going on in the backdrop and
a process (running inside that VM) is accessing (reading/writing) into pages
in memory.
1. The hypervisor maintains shadow page-table with *read-only" permission
for all the pages. When a page is being written by the afore-menioned
process (and assume the page is writable), what is the way for the
hypervisor to know about it? There may be two possibilities as mentioned
below (please let me know which one is correct):
a. The guest-OS does not raise any trap (as the page is writable);
but, because a page was modified, he informs the hypervisor. Is this
correct?
b. Following the writing, the TLB has to be updated. Because of that
the hypervisor comes to know about the modification. Is this correct?
Put in other words, what exactly happens to let hypervisor track
page-modification with the help of shadow page-table or dirty-bitmap?
2. One may want to update TLB entries for the pages updated during a
pre-copy round in a batch for better performance? Then, is it the case that
hypervisor comes to know about all the modified pages during the end of a
pre-copy round when the updation of TLB is over? Pleaes note that this would
be possible for only those pages whose entries were already available in
TLB. Now, what''d happen if the writing process has resulted in a TLB
miss in
the first place?
Thanks in advance,
Amitayu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Amitayu Das wrote:> I had few questions regarding the mechanism employed by the > hypervisor for figuring out the pages modified during a pre-copy > round of a migration of a VM. Please assume that a migration of a > VM is going on in the backdrop and a process (running inside that > VM) is accessing (reading/writing) into pages in memory.The mechanism is simpler than your two descriptions. The hypervisor manages the -real- page tables and the processor modifies those page table entries upon page modification by the guest O/S or a process of it. So, the hypervisor knows exactly what the process has touched. The guest O/S sees the shadow copy that is read- only. I do not know with what frequency (if at all) that the shadow copy PTE dirty page bits are set. (Maybe there''s a hypervisor call to update the shadow copy PTE dirty bits?) To answer your question this is how I presume the mechanism works: 1) Assume a page is initially dirty 2) Xen determines to ship that page to the destination 3) Xen marks that page read only, see below 4) Xen initiates shipping the page to the destination Up to this point the guest O/S has been free to continue execution so long as it does not attempt to write to the page in question. If it does it will be halted until step 7 below. 5) Xen receives acknowledgment from the destination machine 6) Xen clears the dirty bit for the page and marks it writable 7) If the guest O/S had been paused, this is where the guest O/S could be resumed That''s what I believe to be the process. -- Randy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel