Stas Sergeev

I have a doubt that this works. Fault stalls both guest and host. After fault is handled, guest resumes and the host quickly starts the update procedure in a separate...

> 198 had some performance issues for the dirty log, but I could properly benchmark that too. I wonder why I was claiming that the slow-down is the result of...

> It turns out the slow down indeed had to do everything with the bank switching (with direct source mapping) So I knew it? :) Interesting. > dirties all pages...

> now if the update happens early during (4) but with (3) eliminated, it'll just update the whole bank, > then protect it, and the page faults continue. And it...

And getting this even wider, we can also have a time-out counter for the "reprotect" bit. So I think this technique is both simple to implement, and actually expresses what...

Or actually no need to any "reprotect" bit - just a non-zero counter means "decrement and reprotect when 0". So I guess we can use 1 byte per page: 7...

> But update_screen is triggered from SIGALRM But this SIGALRM stuff will go away! You can find many, many things right now which already have a separate thread but still...

> against my trick obviously since the trick is a subset of dirtying permanently. In that case why can't we have the memcpy()/always_dirty from the very beginning? You haven't found...

I still don't understand why do you call this "minimize syscalls during a bank-switch". You took bank-switch as a heuristic point after which you expect the excessive write, and it...

Yes, sounds interesting to maintain the new mapping buffer somewhere in vga.mem.xxx. It will likely be useful later not only for kvm, but also for memcpy mode (when the corresponding...