From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: memop struct packing, 32/64 bits Date: Sun, 22 Jan 2012 20:43:15 +0000 Message-ID: References: <20120122203714.GB30288@andromeda.dapyr.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120122203714.GB30288@andromeda.dapyr.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com, Andres Lagar-Cavilla , ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 22/01/2012 20:37, "Konrad Rzeszutek Wilk" wrote: >>> luck? Am I missing something? >> >> Where older structs were not 32/64-bit invariant, compat shims were >> implemented. See common/compat/memory.c, for example. Well worth avoiding >> that! > > So for the "Fun" of it I tried to see if the 'struct > xen_processor_performance' has some 32/64-bit issues and was surprised > to find they do. What I am more surprised to find is that nobody seems > to have had any troubles with this as it seems to have been there since > it was initially implemented. The major issue would have been with the > 'shared_type', 'domain_info' and the pointer to the 'states' being at > different offsets (So when running a 32-bit dom0 with a 64-bit > hypervisor). It works because x86/64 Xen has a compat shim for that platform hypercall command, which it uses when the caller is a 32-bit guest. See xen/include/xlat.lst, xen/include/compat/platform.h (auto-generated), xen/arch/x86/x86_64/platform_hypercall.c. For more details, ask Jan -- he implemented most of it. ;-) -- Keir > The attached little C program has the identified issues and the > // FIX is my attempt at making the structs of the same size on 32 and 64 > bit builds. Right now when built as 32-bit the struct is 96 bytes, while on > 64-bit it is 104. > > Was wondering what is the right fix? The thoughts I had was to either > leave them as be and the domain would have to figure out whether the > hypervisor > is 32-bit or 64-bit and provide the _right_ structure. > > Or perhaps fix it and provide a "version" hypercall, but that would not > be backwards compatible.