[libvirt] [PATCH] qemu: process: Fix automatic setting of locked memory limit for VFIO

Peter Krempa pkrempa at redhat.com
Wed Nov 11 06:07:20 UTC 2015


On Tue, Nov 10, 2015 at 09:40:34 -0700, Alex Williamson wrote:
> On Fri, 2015-11-06 at 08:30 +0100, Peter Krempa wrote:

[...]

> Now the next question is whether this peer-to-peer DMA is useful, or
> even used.  I have heard of users assigning multiple AMD cards to a
> system and making use of AMD's XDMA crossfire support, which certainly
> seems like it's using this capability.  NVIDIA may follow along, but
> they seem to limit SLI in their driver.  But as I said, these aren't
> counting against the locked memory limit and there's probably very
> little potential use of peer-to-peer between assigned and emulated
> devices.  At the time I first implemented VFIO, I couldn't see a way to
> tell the difference between mappings for emulated and assigned devices,
> they're all just opaque mappings.  However, I think we could now be a
> bit smarter to figure out the device associated with the MemorySection
> and skip emulated device regions.  If we were to do that, we could
> expose it as a new option to vfio-pci, so libvirt could probe for it and

Hmm, this might be interresting in the future. We'll probably have to
work out though the case when the VM is started fresh, since we really
can't ask qemu before starting it.

> maybe remove the fudge factor on the lock limit.  Thanks,

Thank you very much for the explanation. I've tried to condense the key
points into a improved comment in our code:

http://www.redhat.com/archives/libvir-list/2015-November/msg00341.html

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151111/938e0be6/attachment-0001.sig>


More information about the libvir-list mailing list