From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Should we revert "mm: New XENMEM space, XENMAPSPACE_gmfn_range"? Date: Wed, 1 Aug 2012 19:08:21 +0100 Message-ID: <20120801180821.GA96456@ocelot.phlegethon.org> References: <1321471508-31633-1-git-send-email-jean.guyader@eu.citrix.com> <1321471508-31633-2-git-send-email-jean.guyader@eu.citrix.com> <1321471508-31633-3-git-send-email-jean.guyader@eu.citrix.com> <1321471508-31633-4-git-send-email-jean.guyader@eu.citrix.com> <1321471508-31633-5-git-send-email-jean.guyader@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Konrad Rzeszutek Wilk , "allen.m.kay@intel.com" , Jean Guyader , Jean Guyader , "JBeulich@suse.com" , Attilio Rao List-Id: xen-devel@lists.xenproject.org At 18:55 +0100 on 01 Aug (1343847341), Stefano Stabellini wrote: > I was reading more about this commit because this patch breaks the ABI > on ARM, when I realized that on x86 there is no standard that specifies > the alignment of fields in a struct. > As a consequence I don't think we can really be sure that between .domid > and .space we always have 16 bits of padding. > I am afraid that if a user compiles Linux or another guest kernel with a > compiler other than gcc, this hypercall might break. In fact it already > happened just switching from x86 to ARM. AIUI, reverting this patch won't solve that problem - either a compiler adds 16 bytes of padding (as GCC and clang do), in which case we can use that area of the new argument, or it doesn't, in which case it's already not compatible with a GCC-built xen. > Also, considering that the memory.h interface is supposed to be ANSI C, > isn't it wrong to assume compiler specific artifacts anyway? Yes - people writing Windows drivers have this sort of alignment/padding issue already in a number of places. But since, as you say, there's no standard describing this, the best we can do is keep any _new_ interfaces size-aligned and explicitly sized. Tim.