From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aabMC-0002rU-Vy for mharc-grub-devel@gnu.org; Mon, 29 Feb 2016 22:52:20 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aabMA-0002r9-88 for grub-devel@gnu.org; Mon, 29 Feb 2016 22:52:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aabM7-0002Yg-1n for grub-devel@gnu.org; Mon, 29 Feb 2016 22:52:18 -0500 Received: from mail-lb0-x241.google.com ([2a00:1450:4010:c04::241]:36851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aabM6-0002YC-G4 for grub-devel@gnu.org; Mon, 29 Feb 2016 22:52:14 -0500 Received: by mail-lb0-x241.google.com with SMTP id gn5so6968775lbc.3 for ; Mon, 29 Feb 2016 19:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rywtIkYYP7CdJHIOt+Y0NF0T2fUyGDvwIIYn3txq+pk=; b=ovq4L3AyETC1HHfldgOgoMiWmsQlgUaqS0Scsa5NoM56HTI/82WBKfJq5dEd5/bl68 TwMWRDDKcjDu1wGrNxSeuBV4DJSIbvyyvv+sXRoSPu8yFVcDFULgteJ+7RJbiaavJhXM U1rlF701/rlkapZhWjoJ+xPhpiX2diSNc+OfMvzP0x2YNH0YvbbP5bblLUBM8CwW+Frv CRlue+7QMnVNbF1lDnPetYQMIDlGfp0KUsyCiY2LdUiLchUsF2/Ef1RigJaYH3Aw4jD/ QxQq+CJSrThyEReBsgbDI+hIY7ARQmmJ5lbGJfmBuWQUUCsGoEfhVoroMnV/BDrJvV9V NnSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rywtIkYYP7CdJHIOt+Y0NF0T2fUyGDvwIIYn3txq+pk=; b=HmBGI7agNqwdZ3Wki/iJFNwdZ3SnjKVa8t01sD//kI21YCZeacSq1BG8kZs8duX97J 1Bf53K8do+LY6AJfqaQxAj6L1lc2o4ehy2+bskEaq8eGaEffPy0jCqI9AuKlYPoBsBbO BGEDytgxTiwTiR+vEniOehzyipv06RGB0crMEphZVjBzbImmJbsH/4xUxNok7mPdWcuL 9/x4ZNUEfeiYagf+a4lcqQiqjBtUrT+7Zkky4eR/thTMvMV9xlnPF7oKaVkMBTfcsMdi 0g7JeBX18DAfC5UNaXZPqYo2C/KUDhMZo/D5tsbRZaENz+eCT0D1iaQdA/KoafCgRRA+ jnQQ== X-Gm-Message-State: AD7BkJKo3Jcd5OJusFNdMEu6Za4tHevwU5oCv1QDWU7D0Mw7C8SIUkWFJD3vQZgjqdjWgA== X-Received: by 10.112.73.69 with SMTP id j5mr5599254lbv.124.1456804332881; Mon, 29 Feb 2016 19:52:12 -0800 (PST) Received: from [192.168.1.41] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id ub6sm4460274lbb.17.2016.02.29.19.52.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 19:52:11 -0800 (PST) Subject: Re: [PATCH v4 10/11] xen: modify page table construction To: The development of GNU GRUB , Daniel Kiper References: <1456120999-5639-1-git-send-email-jgross@suse.com> <1456120999-5639-11-git-send-email-jgross@suse.com> <20160222091748.GO3482@olila.local.net-space.pl> <56CAD4E0.80304@suse.com> <20160222121858.GQ3482@olila.local.net-space.pl> <56CAFF66.1080709@suse.com> <20160222124805.GS3482@olila.local.net-space.pl> <56CB09AE.3040301@suse.com> <56CF4903.6020304@gmail.com> <56D40BB6.6090904@suse.com> <56D4374F.5050209@suse.com> From: Andrei Borzenkov Message-ID: <56D511EA.4000503@gmail.com> Date: Tue, 1 Mar 2016 06:52:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D4374F.5050209@suse.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::241 Cc: phcoder@gmail.com, mchang@suse.com, xen-devel@lists.xen.org X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 03:52:19 -0000 29.02.2016 15:19, Juergen Gross пишет: > On 29/02/16 10:13, Juergen Gross wrote: >> On 25/02/16 19:33, Andrei Borzenkov wrote: >>> 22.02.2016 16:14, Juergen Gross пишет: >>>> On 22/02/16 13:48, Daniel Kiper wrote: >>>>> On Mon, Feb 22, 2016 at 01:30:30PM +0100, Juergen Gross wrote: >>>>>> On 22/02/16 13:18, Daniel Kiper wrote: >>>>>>> On Mon, Feb 22, 2016 at 10:29:04AM +0100, Juergen Gross wrote: >>>>>>>> On 22/02/16 10:17, Daniel Kiper wrote: >>>>>>>>> On Mon, Feb 22, 2016 at 07:03:18AM +0100, Juergen Gross wrote: >>>>>>>>>> diff --git a/grub-core/lib/xen/relocator.c b/grub-core/lib/xen/relocator.c >>>>>>>>>> index 8f427d3..a05b253 100644 >>>>>>>>>> --- a/grub-core/lib/xen/relocator.c >>>>>>>>>> +++ b/grub-core/lib/xen/relocator.c >>>>>>>>>> @@ -29,6 +29,11 @@ >>>>>>>>>> >>>>>>>>>> typedef grub_addr_t grub_xen_reg_t; >>>>>>>>>> >>>>>>>>>> +struct grub_relocator_xen_paging_area { >>>>>>>>>> + grub_xen_reg_t start; >>>>>>>>>> + grub_xen_reg_t size; >>>>>>>>>> +}; >>>>>>>>>> + >>>>>>>>> >>>>>>>>> ... this should have GRUB_PACKED because compiler may >>>>>>>>> add padding to align size member. >>>>>>>> >>>>>>>> Why would the compiler add padding to a structure containing two items >>>>>>>> of the same type? I don't think the C standard would allow this. >>>>>>>> >>>>>>>> grub_xen_reg_t is either unsigned (32 bit) or unsigned long (64 bit). >>>>>>>> There is no way this could require any padding. >>>>>>> >>>>>>> You are right but we should add this here just in case. >>>>>> >>>>>> Sorry, I don't think this makes any sense. The C standard is very clear >>>>>> in this case: a type requiring a special alignment has always a length >>>>>> being a multiple of that alignment. Otherwise arrays wouldn't work. >>>>> >>>>> Sorry, I am not sure what do you mean by that. >>>> >>>> The size of any C type (no matter whether it is an integral type like >>>> "int" or a structure) has always the same alignment restriction as the >>>> type itself. So a type requiring 8 byte alignment will always have a >>>> size of a multiple of 8 bytes. This is mandatory for arrays to work, as >>>> otherwise either the elements wouldn't be placed consecutively in memory >>>> or the alignment restrictions wouldn't be obeyed for all elements. >>>> >>> >>> I too not follow how it is relevant to this case. We talk about internal >>> padding between structure members, not between array elements. >>> >>>> For our case it means that two structure elements of the same type will >>>> never require a padding between them, thus the annotation with "packed" >>>> can't serve any purpose. >>>> >>> >>> Well, I am not aware of any requirement. Compiler may add arbitrary >>> padding between structure elements; it is only prohibited to add padding >>> at the beginning. Sure, it would be unusual, but never say "never" ... >>> also should Xen ever be ported to architecture where types are not >>> self-aligned it will become an issue. >> >> So you are telling me that _all_ interfaces between e.g. Linux, grub2, >> Xen and all wire protocols not attributed with "packed" are just wrong? >> >> Sorry, I don't think this is true. > > Okay, just found a reference: The x86 ABI states: > > Aggregates and Unions > --------------------- > Structures and unions assume the alignment of their most strictly > aligned component. Each member is assigned to the lowest available > offset with the appropriate alignment. The size of any object is always > a multiple of the object‘s alignment. > > I don't think any x86 C-compiler will violate the x86 ABI. > Thank you! I was not really objecting, more thinking loud, because I missed such explicit statemrnt. Could you post link?