From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aZ0jY-0002x9-As for mharc-grub-devel@gnu.org; Thu, 25 Feb 2016 13:33:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ0jV-0002w1-Jv for grub-devel@gnu.org; Thu, 25 Feb 2016 13:33:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZ0jQ-0000sK-E7 for grub-devel@gnu.org; Thu, 25 Feb 2016 13:33:49 -0500 Received: from mail-lb0-x232.google.com ([2a00:1450:4010:c04::232]:35435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZ0jQ-0000sD-1J for grub-devel@gnu.org; Thu, 25 Feb 2016 13:33:44 -0500 Received: by mail-lb0-x232.google.com with SMTP id bc4so33969934lbc.2 for ; Thu, 25 Feb 2016 10:33:43 -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-type:content-transfer-encoding; bh=ctcEdGXQlgRy2EFEaYUrNbIU1/FSR/2IXWiTxAZFp94=; b=hWfA7LWMJ5d0oZ1m+CZQbSh255Rft55icwBIy8c2wLjsfHoRAh0CzRT+SLTS7/egPG WVpEJb5QNg7zB3dNMINLyDK8UafwyWX3awnYKqvzeiLFHWFADQhgwwNQiZwPWKfiVuhU 4BBjrowO5sC2baPMJMMDLqoEMNgEHqI1c9K2XwEqQTQsaOyemPMhUKxlrzi49DgTMU7v cnTRj9gcsMxzhYucyuX/k7exFJ5NZDc/M89jdLPTLKCvTK4QoFtCJdXJ+smmI2MUe95E hHtNdqTxwIA4xmgomVPrPwokJQkbEQuMpPf9EMekDXmF34Vw5KCb46H1cHtbdVZsW+L1 HCWQ== 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-type :content-transfer-encoding; bh=ctcEdGXQlgRy2EFEaYUrNbIU1/FSR/2IXWiTxAZFp94=; b=MJxfPFeWOy6grFP1Y0JFUNOCgulEUvVrQZddxMorehF90NKq5ZGTwSaN2ZUqjGhCDl w27KroKM84w4hPWj56Sfc5fXxoJ9fgphtAXwfbQlQlZ2+yas1HB8sBHVGwPIRiXolWT5 FGCWHglvduN90c+jGv6K7W4nEHjkmlEnFoKxnYv0WZLZvxPM85Pj5BU2bgI/np/nn1Bq y/Pw344tWSqmE3/w/x2LUMVVDVI2CavgkI3us+FAvz0SQX60GrsCSO+XMerqZsnM82ky KpRaVSMPzRLJI+pcsIB1nwc223mcoqjInS/rxoPdLGaQlXXxCzQmqzW5gzS+Yq2uFFK6 pwnQ== X-Gm-Message-State: AG10YORZpQBHcUjT7HRyWc3zieBHfNWNJ9Xxrh43yIKYYgdVWD+cmLPPT40a1teNqcCOFQ== X-Received: by 10.112.63.231 with SMTP id j7mr719436lbs.52.1456425223088; Thu, 25 Feb 2016 10:33:43 -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 z194sm1322411lfd.20.2016.02.25.10.33.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 10:33:42 -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> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56CF4903.6020304@gmail.com> Date: Thu, 25 Feb 2016 21:33:39 +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: <56CB09AE.3040301@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::232 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: Thu, 25 Feb 2016 18:33:50 -0000 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. >> >>> Adding GRUB_PACKED would make the code less clear IMO. Finding such a >>> qualifier in some code I want to modify would make me search for the >>> reason for it which isn't existing. >> >> If maintainers do not object I am not going to insist on that any longer. > It seems inconsistent through the code, really. But I think in this case it should be packed. It does not look like it is performance critical and it ensures we always match assembler code.