[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v3 6/8] admin: Add theory of operation for write recording commands
On 11/17/2023 5:59 PM, Parav Pandit wrote:
hypervisor provides GPA to the guest, but the VA can be very high address, means can be u64.From: Zhu, Lingshan <lingshan.zhu@intel.com> Sent: Friday, November 17, 2023 3:23 PM On 11/17/2023 5:41 PM, Parav Pandit wrote:From: Michael S. Tsirkin <mst@redhat.com> Sent: Friday, November 17, 2023 3:08 PM On Fri, Nov 17, 2023 at 09:14:21AM +0000, Parav Pandit wrote:From: Michael S. Tsirkin <mst@redhat.com> Sent: Friday, November 17, 2023 2:16 PM In any case you can safely assume that many users will have migration that takes seconds and minutes.Strange, but ok. I don't see any problem with current method. 8MB is used for very large VM of 1TB takes minutes. Should be fine.The problem is simple: vendors selling devices have no idea how large the VM will be. So you have to over-provision for the max VM size. If there was a way to instead allocate that in host memory, that would improve on this.Not sure what to over provision for max VM size. Vendor does not know how many vcpus will be needed. It is no differentproblem.When the VM migration is started, the individual tracking range is supplied bythe hypervisor to device.Device allocates necessary memory on this instruction. When the VM with certain size is provisioned, the member device can beprovisioned for the VM size.And if it cannot be provisioned, possibly this may not the right member deviceto use at that point in time. I think Michael means the guest memory can be large, and the device may DMA anywhere, so the device should prepare for the worst case, that could be U64 size which can be over-provision.No. that is not true. The hypervisor supplies the range of addresses on which to track the dirty pages. So for sure it is not u64.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]