Re: [PATCH 3/3] arm, arm64: KVM: handle potential incoherency of readonly memslots

Christoffer Dall
2014-11-22T10:18:08Z

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