On 2019/9/16 上午9:51, Tian, Kevin wrote:
Hi, Jason
We had a discussion about dirty page tracking in VFIO, when vIOMMU
is enabled:
https://lists.nongnu.org/archive/html/qemu-devel/2019-09/msg02690.html
It's actually a similar model as vhost - Qemu cannot interpose the fast-path
DMAs thus relies on the kernel part to track and report dirty page information.
Currently Qemu tracks dirty pages in GFN level, thus demanding a translation
from IOVA to GPA. Then the open in our discussion is where this translation
should happen. Doing the translation in kernel implies a device iotlb flavor,
which is what vhost implements today. It requires potentially large tracking
structures in the host kernel, but leveraging the existing log_sync flow in
Qemu.
On the other hand, Qemu may perform log_sync for every removal of IOVA
mapping and then do the translation itself, then avoiding the GPA awareness
in the kernel side. It needs some change to current Qemu log-sync flow, and
may bring more overhead if IOVA is frequently unmapped.
So we'd like to hear about your opinions, especially about how you came
down to the current iotlb approach for vhost.
We don't consider too much in the point when introducing vhost. And
before IOTLB, vhost has already know GPA through its mem table
(GPA->HVA). So it's nature and easier to track dirty pages at GPA level
then it won't any changes in the existing ABI.
For VFIO case, the only advantages of using GPA is that the log can then
be shared among all the devices that belongs to the VM. Otherwise
syncing through IOVA is cleaner.
Thanks
p.s. Alex's comment is also copied here from original thread.
So vhost must then be configuring a listener across system memory
rather than only against the device AddressSpace like we do in vfio,
such that it get's log_sync() callbacks for the actual GPA space rather
than only the IOVA space. OTOH, QEMU could understand that the device
AddressSpace has a translate function and apply the IOVA dirty bits to
the system memory AddressSpace. Wouldn't it make more sense for
QEMU
to perform a log_sync() prior to removing a MemoryRegionSection within
an AddressSpace and update the GPA rather than pushing GPA awareness
and potentially large tracking structures into the host kernel?
Thanks
Kevin
