Re: Checking guest memory pages changes from host userspace

[Avi Kivity <avi@redhat.com>]

On 06/21/2009 09:46 PM, Alexander Graf wrote:
>> You can use the dirty memory logging API.  vga uses this to track 
>> which regions of the screen have changed, and live migration uses it 
>> to allow the guest to proceed while copying its memory to the other 
>> node.  It works exactly by write protecting guest memory and trapping 
>> the resultant fault.
>
>
> I stumbled across this on my ppc implementation: Is there an obvious 
> reason we don't use the pte's dirty bit?


Yes:

> I don't know which operation is more frequent - writing into dirty 
> mapped memory or reading the dirty map. And I have no idea how long it 
> would take to find out dirty pages...

The cost of write protection is one fault per dirtied spte.  The cost of 
looking at the dirty bit is a cache miss per spte (could be reduced by 
scanning in spte order rather than gfn order).

The problem is when you have a low percentage of memory dirtied.  Then 
you're scanning a lot of sptes to find a few dirty ones - so the cost 
per dirty page goes up.

We've talked about write-protecting the upper levels first, but given a 
random distribution of writes, that doesn't help much.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.