From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] blkif: add indirect descriptors interface to public headers Date: Tue, 12 Nov 2013 09:42:29 -0500 Message-ID: <20131112144229.GA9435@phenom.dumpdata.com> References: <1384252612-22573-1-git-send-email-roger.pau@citrix.com> <9AAE0902D5BC7E449B7C8E4E778ABCD017021D@AMSPEX01CL01.citrite.net> <20131112142254.GC9306@phenom.dumpdata.com> <1384266541.10204.14.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VgFAr-0001YR-Ol for xen-devel@lists.xenproject.org; Tue, 12 Nov 2013 14:42:38 +0000 Content-Disposition: inline In-Reply-To: <1384266541.10204.14.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , "Keir (Xen.org)" , Jan Beulich , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On Tue, Nov 12, 2013 at 02:29:01PM +0000, Ian Campbell wrote: > On Tue, 2013-11-12 at 09:22 -0500, Konrad Rzeszutek Wilk wrote: > > > > > +struct blkif_request_indirect { > > > > + uint8_t operation; /* BLKIF_OP_INDIRECT */ > > > > + uint8_t indirect_op; /* BLKIF_OP_{READ/WRITE} */ > > > > + uint16_t nr_segments; /* number of segments */ > > > > > > This is going to be a problem. What alignment boundary are you > > expecting the next field to start on? AFAIK 32-bit gcc will 4-byte > > align it, 32-bit MSVC will 8-byte align it. > > > > > > > Oh no. I thought that the Linux one had this set correctly, ah it did: > > > > > > struct blkif_request_indirect { > > [...] > > } __attribute__((__packed__)); > > That attribute packed isn't allowed in the public interface headers. Right. I had hit that at some point with putting in a u64 and seeing it mushroom up while if I did two u32 it padded it nicely. Perhaps that is what we should do? The Linux struct has the same size whether it be 64-bit or 32-bit. > > Since compilers do differ in their packing, and guests may be using > various pragmas, it might be useful to write down that for x86 these > headers are to be treated as using the ABI (gcc? Some Intel > standard?). Or perhaps just mention the size of the structure and offset? > > For ARM we reference the specific standard[0]. It is up to the guest OS > to make sure that it's version of the headers lay things out following > that standard (NB Linux blkif.h is currently buggy on ARM in this > regard, Julien has the details). > > Ian. > > [0] > http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,arch-arm.h.html#incontents_arm_abi >