The iommu is locked in there early and the iommu element is what is passed from
userspace.
That represents the vfio container for this device (container->fd)
qemu:
if (ioctl(container->fd, VFIO_IOMMU_MAP_DMA, &map) == 0
kernel:
static long vfio_iommu_type1_ioctl(void *iommu_data,
unsigned int cmd, unsigned long arg)
struct vfio_iommu *iommu = iommu_data;
[... into vfio_dma_do_map ...]
mutex_lock(&iommu->lock);
There isn't much divide and conquer splitting that seems easily possible for
now :-/
Down there while this lock is held all the memory size must be pinned
-> vfio_pin_pages_remote
Which gets the biggest chunk it can to then map it
-> vfio_iommu_map
This is repeated until all of the requested size is handled.
Establishing iommu maps is known to be expensive, an assumption would be that
in the semi-fast cases is either:
- memory is still non-fragmented so we only need a few calls
- the iommu is sort of async-busy from the former work (same calls, but longer)
That should be visible in the amount of vfio_pin_pages_remote if we don't miss
some.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1838575
Title:
passthrough devices cause >17min boot delay
Status in linux package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Incomplete
Bug description:
Adding passthrough devices to a guest introduces a boot delay of > 17
minutes. During this time libvirt reports the guest to be "paused".
The delay does not seem to scale with the # of hostdevs - that is, 1
hostdev causes about a 17min delay, while 16 only bumps that up to
~18min. Removing all hostdevs avoids the delay.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838575/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
