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

[Peter Krempa]

On Thu, Nov 05, 2015 at 08:41:46 -0700, Alex Williamson wrote:
> On Thu, 2015-11-05 at 16:27 +0100, Peter Krempa wrote:
> > On Wed, Nov 04, 2015 at 17:16:53 -0700, Alex Williamson wrote:

[...]

> The power devs will need to speak to what their locked memory
> requirements are and maybe we can come up with a combined algorithm that
> works good enough for both, or maybe libvirt needs to apply different
> algorithms based on the machine type.  The x86 limit has been workinga

Okay, that seems reasonable. I'll extract the code that sets the limit
into a helper, so that there's a central point where this stuff can be
tweaked and made machine dependent.

> well for us, so I see no reason to abandon it simply because we tried to
> apply it to a different platform and it didn't work.  Thanks,

As of the x86 lock limit. Currently the code states the following:

        /* VFIO requires all of the guest's memory to be
         * locked resident, plus some amount for IO
         * space. Alex Williamson suggested adding 1GiB for IO
         * space just to be safe (some finer tuning might be
         * nice, though).
         */

Disregarding the empirical evidence that this worked until now on x86
the comment's message here is rather unsure about the actual size used
at this point and hints it might need tweaking. If I'm going to move
this I'd really like to remove the uncertainity from the message.

So will I be able to justify:
- dropping "some" from some ammount for IO space
- replacing "Alex Williamson suggested adding" by something more
  scientifical

I think the mlock size will be justified far more with comment like:

  /* VFIO requires all of guest's memory and memory for the IO space to
   * be locked persistent.
   *
   * On x86 the IO space size is 1GiB.
   * [some lines for possibly other platforms]
   */

Is it valid to make such change or do we need to keep the ambiguity and
just reference the empirical fact that it didn't break yet?

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/20151106/d925a3fa/attachment-0001.sig>