Avi Kivity wrote: > Jan Kiszka wrote: >> Avi or Uri, >> >> could you explain the first and third hunk? Why are they needed in >> qemu-kvm, and will we also need something comparable upstream? They do >> not look very beautiful. >> >> > > These date from the bad old days where we relied on phys_ram_base. I > think this is obsolete. > > Since we reserve these memory addresses, it won't do any harm, but we > can certainly remove them. That's great, will drop it. > >> The second hunk, I guess, should become a kvm hook to >> cpu_physical_memory_get_dirty - or is this too costly for other users of >> this inline function? >> > > Note the dependency on current_addr: this is meant to happen every time > we cycle through all memory, so it doesn't fit in > cpu_physical_memory_get_dirty(). Yes, I realized that there is already cpu_physical_sync_dirty_bitmap(), and I will simply use this. > >> And does anyone knows further migration-related hunks that are missing >> upstream (except for the KVM hook in >> cpu_physical_memory_set_dirty_tracking)? >> >> > > We need to make sure vga plays well with this, like we discussed. Already implemented in ~30 additional LOC. Just have to test the whole series (found some more things to clean up) Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
