Re: [libvirt] [PATCH v2] domain: fix parsing of memory tunables on 32-bit machines

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!

> + * 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.