On 10/31/2014 12:20 AM, Martin Kletzander wrote: > On Thu, Oct 30, 2014 at 02:00:34PM -0600, Eric Blake wrote: >> Commit 6c9a8a4 (Oct 2014) exposed a long-standing issue on 32-bit >> machines: code related to virDomainSetMemoryParameters has always >> been documented as using a 64-bit limit, but it was implemented by >> calling virDomainParseMemory which enforced an 'unsigned long' >> limit. Since VIR_DOMAIN_MEMORY_PARAM_UNLIMITED capped to a >> long is -1, but virDomainParseScaledValue no longer accepts >> negative values, an attempt to use 2^53-1 as a hard memory limit >> started failing the testsuite. However, the problem with capping >> things artificially low has existed for much longer - ever since >> commits 4888f0fb and 2e22f23 (Mar 2012) switched internal tracking >> from 'unsigned long' to 'unsigned long long' (prior to that time, >> the cap was a side-effect of the choice of types). We _have_ to >> cap the balloon memory values, (no thanks to baked in 'unsigned long' >> of API such as virDomainSetMaxMemory or virDomainGetInfo with no > > Oh, this is why it needs to be capped. That makes sense. And great > to have it in the comment next to those variables! Comments can make a world of difference :) >> + * exceed VIR_DOMAIN_MEMORY_PARAM_UNLIMITED once scaled; additionally, >> + * if CAPPED is true, the value must fit within an unsigned long (only >> + * matters on 32-bit platforms). Return 0 on success, -1 on failure >> + * after issuing error. */ > > The last sentence (Return ...) could be in its own paragraph even > though our documentation is not created for these functions. > > ACK with that and safe for freeze and also build-breaker for 32-bit > machines. Tweaked and pushed. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list