qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] vhost, iova, and dirty page tracking


From: Jason Wang
Subject: Re: [Qemu-devel] vhost, iova, and dirty page tracking
Date: Thu, 19 Sep 2019 20:39:28 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0


On 2019/9/19 下午7:14, Paolo Bonzini wrote:
On 19/09/19 09:16, Tian, Kevin wrote:
why GPA1 and GPA2 should be both dirty?
even they have the same HVA due to overlaping virtual address space in
two processes, they still correspond to two physical pages.
don't get what's your meaning :)
The point is not leave any corner case that is hard to debug or fix in
the future.

Let's just start by a single process, the API allows userspace to maps
HVA to both GPA1 and GPA2. Since it knows GPA1 and GPA2 are equivalent,
it's ok to sync just through GPA1. That means if you only log GPA2, it
won't work.
I noted KVM itself doesn't consider such situation (one HVA is mapped
to multiple GPAs), when doing its dirty page tracking. If you look at
kvm_vcpu_mark_page_dirty, it simply finds the unique memslot which
contains the dirty gfn and then set the dirty bit within that slot. It
doesn't attempt to walk all memslots to find out any other GPA which
may be mapped to the same HVA.

So there must be some disconnect here. let's hear from Paolo first and
understand the rationale behind such situation.
In general, userspace cannot assume that it's okay to sync just through
GPA1.  It must sync the host page if *either* GPA1 or GPA2 are marked dirty.


Maybe we need document this somewhere.



The situation really only arises in special cases.  For example,
0xfffe0000..0xffffffff and 0xe0000..0xfffff might be the same memory.
 From "info mtree" before the guest boots:

     0000000000000000-ffffffffffffffff (prio -1, i/o): pci
       00000000000e0000-00000000000fffff (prio 1, i/o): alias isa-bios
@pc.bios 0000000000020000-000000000003ffff
       00000000fffc0000-00000000ffffffff (prio 0, rom): pc.bios

However, non-x86 machines may have other cases of aliased memory so it's
a case that you should cover.

Paolo


Any other issue that still need to be covered consider userspace need to sync both GPAs?

Thanks




reply via email to

[Prev in Thread] Current Thread [Next in Thread]