On Fri, Nov 21, 2014 at 05:50:43PM -0800, Mario Smarduch wrote: > On 11/21/2014 03:19 AM, Christoffer Dall wrote: > > Hi Mario, > > > > On Wed, Nov 19, 2014 at 03:32:31PM -0800, Mario Smarduch wrote: > >> Hi Laszlo, > >> > >> couple observations. > >> > >> I'm wondering if access from qemu and guest won't > >> result in mixed memory attributes and if that's acceptable > >> to the CPU. > >> > >> Also is if you update memory from qemu you may break > >> dirty page logging/migration. Unless there is some other way > >> you keep track. Of course it may not be applicable in your > >> case (i.e. flash unused after boot). > >> > > I'm not concerned about this particular case; dirty page logging exists > > so KVM can inform userspace when a page may have been dirtied. If > > userspace directly dirties (is that a verb?) a page, > I would think so, I rely on software too much :) > > then it already knows that it needs to migrate that page and > > deal with it accordingly. > > > > Or did I miss some more subtle point here > > QEMU has a global migration bitmap for all regions initially set > dirty, and it's updated over iterations with KVM's dirty bitmap. Once > dirty pages are migrated bits are cleared. If QEMU updates a > memory region directly I can't see how it's reflected in that migration > bitmap that determines what pages should be migrated as it makes > it's passes. On x86 if host updates guest memory it marks that > page dirty. > > But virtio writes to guest memory directly and that appears to > work just fine. I read that code sometime back, and will need to revisit. > In any case, that's a QEMU implementation issue and nothing the kernel needs to be concerned with. -Christoffer -- 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
