[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Logging dirty pages from vhost-net in-kernel with vIOMM
Re: [Qemu-devel] Logging dirty pages from vhost-net in-kernel with vIOMMU
Thu, 6 Dec 2018 15:33:02 +0800
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
On 2018/12/5 下午10:47, Jintack Lim wrote:
On Tue, Dec 4, 2018 at 8:30 PM Jason Wang <address@hidden> wrote:
On 2018/12/5 上午2:37, Jintack Lim wrote:
I'm wondering how the current implementation works when logging dirty
pages during migration from vhost-net (in kernel) when used vIOMMU.
I understand how vhost-net logs GPAs when not using vIOMMU. But when
we use vhost with vIOMMU, then shouldn't vhost-net need to log the
translated address (GPA) instead of the address written in the
descriptor (IOVA) ? The current implementation looks like vhost-net
just logs IOVA without translation in vhost_get_vq_desc() in
drivers/vhost/net.c. It seems like QEMU doesn't do any further
translation of the dirty log when syncing.
I might be missing something. Could somebody shed some light on this?
Good catch. It looks like a bug to me. Want to post a patch for this?
Thanks for the confirmation.
What would be a good setup to catch this kind of migration bug? I
tried to observe it in the VM expecting to see network applications
not getting data correctly on the destination, but it was not
successful (i.e. the VM on the destination just worked fine.) I didn't
even see anything going wrong when I disabled the vhost logging
completely without using vIOMMU.
What I did is I ran multiple network benchmarks (e.g. netperf tcp
stream and my own one to check correctness of received data) in a VM
without vhost dirty page logging, and the benchmarks just ran fine in
the destination. I checked the used ring at the time the VM is stopped
in the source for migration, and it had multiple descriptors that is
(probably) not processed in the VM yet. Do you have any insight how it
could just work and what would be a good setup to catch this?
According to past experience, it could be reproduced by doing scp from
host to guest during migration.
About sending a patch, as Michael suggested, I think it's better for
you to handle this case - this is not my area of expertise, yet :-)
No problem, I will fix this.
Thanks for spotting this issue.