On 02/29/2012 12:16 PM, Takuya Yoshikawa wrote: > > > We may see partial display updates if we do not hold the mmu_lock during > > > xchg loop: it is possible that pages near the end of the framebuffer alone > > > gets updated sometimes - I noticed this problem when I fixed the TLB flush > > > issue. > > > > I don't understand why this happens. > > Because only mmu_lock protects the bitmap for VGA. > > xchg i = 1 > xchg i = 2 > ... > xchg i = N > > We cannot get a complete snapshot without mmu_lock; if the guest faults on > the Nth page during xchg'ing i = 1, 2, ... then the i = N alone will > become newer. Ah, so there is no data corruption (missed dirty bits), just the display is updated inconsistently? I don't think we can get a consistent snapshot anyway, since the guest can update the framebuffer while userspace is processing it. > > But others will be updated by the next call, so the problem is restricted: > maybe not noticeable. > > > > Not a big problem but still maybe-noticeable change, so I think we should > > > do it separately with some comments if needed. > > > > Well if it's noticable on the framebuffer it's also noticable with live > > migration. We could do it later, but we need to really understand it first. > > About live migration, we do not mind whether the bitmap is a complete snapshot. > In addition, we cannot do anything because the emulator can access the bitmap > without mmu_lock. > > What we are doing is calling GET_DIRTY_LOG slot by slot: so already the > result is not a snapshot at all. > > In the end, at the last stage, we will stop the guest and get a complete snapshot. Understood. I don't think we can get a consistent vga snapshot without stopping the guest, and even then, it depends on how the guest updates the framebuffer. > > > > In addition, we do not want to scan the dirty bitmap twice. Using the > > > bits value soon after it is read into a register seems to be the fastest. > > > > Probably. > > > > > BTW, I also want to decide the design of the new API at this chance. > > > > Let's wait with that. We're adding APIs too quickly. Let's squeeze > > everything we can out of the current APIs. > > I agree with you of course. > > At the same time, we cannot say anything without actually implementing > sample userspace programs. > > So I want to see how much improvement the proposed API can achieve. > > I thought this might be a good GSoC project but ... It may be too involved for GSoC, the issues are difficult. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
