From: Jason Wang <jasowang@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>
Cc: 'Alex Williamson' <alex.williamson@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] vhost, iova, and dirty page tracking
Date: Thu, 19 Sep 2019 20:39:28 +0800 [thread overview]
Message-ID: <00084b36-3281-7c8d-5057-427eaabfb174@redhat.com> (raw)
In-Reply-To: <1ec55b2e-6a59-f1df-0604-5b524da0f001@redhat.com>
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
next prev parent reply other threads:[~2019-09-19 13:29 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 1:51 [Qemu-devel] vhost, iova, and dirty page tracking Tian, Kevin
2019-09-16 8:33 ` Jason Wang
2019-09-17 8:48 ` Tian, Kevin
2019-09-17 10:36 ` Jason Wang
2019-09-18 1:44 ` Tian, Kevin
2019-09-18 6:10 ` Jason Wang
2019-09-18 7:41 ` Tian, Kevin
2019-09-18 8:37 ` Tian, Kevin
2019-09-19 1:05 ` Jason Wang
2019-09-19 5:28 ` Yan Zhao
2019-09-19 6:09 ` Jason Wang
2019-09-19 6:17 ` Yan Zhao
2019-09-19 6:32 ` Jason Wang
2019-09-19 6:29 ` Yan Zhao
2019-09-19 6:32 ` Yan Zhao
2019-09-19 9:35 ` Jason Wang
2019-09-19 9:36 ` Yan Zhao
2019-09-19 10:08 ` Jason Wang
2019-09-19 10:06 ` Jason Wang
2019-09-19 10:16 ` Yan Zhao
2019-09-19 12:14 ` Jason Wang
2019-09-19 7:16 ` Tian, Kevin
2019-09-19 9:37 ` Jason Wang
2019-09-19 14:06 ` Michael S. Tsirkin
2019-09-20 1:15 ` Jason Wang
2019-09-20 10:02 ` Michael S. Tsirkin
2019-09-19 11:14 ` Paolo Bonzini
2019-09-19 12:39 ` Jason Wang [this message]
2019-09-19 12:45 ` Paolo Bonzini
2019-09-19 22:54 ` Tian, Kevin
2019-09-20 1:18 ` Jason Wang
2019-09-24 2:02 ` Tian, Kevin
2019-09-25 3:46 ` Jason Wang
2019-09-17 14:54 ` Alex Williamson
2019-09-18 1:31 ` Tian, Kevin
2019-09-18 6:03 ` Jason Wang
2019-09-18 7:21 ` Tian, Kevin
2019-09-19 17:20 ` Alex Williamson
2019-09-19 22:40 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19D57AFB7@SHSMSX104.ccr.corp.intel.com>
2019-09-18 2:15 ` Tian, Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00084b36-3281-7c8d-5057-427eaabfb174@redhat.com \
--to=jasowang@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kevin.tian@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).