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

[Jason Wang <jasowang@redhat.com>]

On 2019/9/20 上午6:54, Tian, Kevin wrote:
>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>> Sent: Thursday, September 19, 2019 7:14 PM
>>
>> 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.
> Agree. In this case the kernel only needs to track whether GPA1 or
> GPA2 is dirtied by guest operations.


Not necessarily guest operations.


>   The reason why vhost has to
> set both GPA1 and GPA2 is due to its own design - it maintains
> IOVA->HVA and GPA->HVA mappings thus given a IOVA you have
> to reverse lookup GPA->HVA memTable which gives multiple possible
> GPAs.


So if userspace need to track both GPA1 and GPA2, vhost can just stop 
when it found a one HVA->GPA mapping there.


>   But in concept if vhost can maintain a IOVA->GPA mapping,
> then it is straightforward to set the right GPA every time when a IOVA
> is tracked.


That means, the translation is done twice by software, IOVA->GPA and 
GPA->HVA for each packet.

Thanks


>
>> 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.
>>
> Above example is read-only, thus won't be touched in logdirty path.
> But now I agree that a specific architecture may define two
> writable GPA ranges with one as the alias to the other, as long as
> such case is explicitly documented so guest OS won't treat them as
> separate memory pages.
>
> Thanks
> Kevin