On Wed, 2015-04-22 at 15:41 +0100, Jan Beulich wrote: > >>> On 22.04.15 at 16:01, <ian.campb...@citrix.com> wrote: > > On Wed, 2015-04-22 at 13:02 +0100, Jan Beulich wrote: > >> Said commit ("libxl_set_memory_target: retain the same maxmem offset on > >> top of the current target") caused a regression for "xl mem-set" > >> against Dom0: While prior to creation of the first domain this works, > >> the first domain creation involving ballooning breaks. Due to "enforce" > >> not being set in the domain creation case, and due to Dom0's initial > >> ->max_pages (in the hypervisor) being UINT_MAX, the calculation of > >> "memorykb" in the first "xl mem-set" adusting the target upwards > >> subsequent to domain creation and termination may cause an overflow, > >> resulting in Dom0's maximum getting to a very small value. This small > >> maximum will the make the subsequent setting of the PoD target fail. > >> > >> Signed-off-by: Jan Beulich <jbeul...@suse.com> > >> --- > >> Note that this only fixes the immediate problem - there appear to be > >> further issues lurking here: > >> - libxl_set_memory_target()'s *_memkb variables all being 32-bit, > >> - libxl_domain_setmaxmem()'s max_memkb parameter being 32-bit, > > > > I think that increasing the width of these variables wouldn't break the > > API guarantee which we make, at least not in a practical way, since any > > existing 32-bit arguments passed will just get promoted. > > No, not even on 64-bit. On 32-bit, two arguments slots are needed > for what so far requires only one. On 64-bit (at least x86-64), the > calling code isn't required to zero-extend a value calculated in a > register (e.g. a result of earlier calculations which had more than > 32 significant bits could be passed unchanged to the called function); > it just so happens that 32-bit arithmetic on registers would always > implicitly zero the upper halves (and iirc that's the same on ARM64).
You seem to be talking about ABI? As I tried to note in my response for libxl we only make guarantees about the API (P not B in the middle). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel