From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cBQ7u-0005H1-75 for mharc-grub-devel@gnu.org; Mon, 28 Nov 2016 12:54:02 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBQ7r-0005Gs-EQ for grub-devel@gnu.org; Mon, 28 Nov 2016 12:54:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBQ7o-0007nA-Cd for grub-devel@gnu.org; Mon, 28 Nov 2016 12:53:59 -0500 Received: from mail-lf0-x242.google.com ([2a00:1450:4010:c07::242]:33393) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBQ7o-0007mr-1O for grub-devel@gnu.org; Mon, 28 Nov 2016 12:53:56 -0500 Received: by mail-lf0-x242.google.com with SMTP id 98so10217490lfs.0 for ; Mon, 28 Nov 2016 09:53:55 -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=O+anphSYWu9Xsx3hQa2y8GzebJCXqq6ezQRrXI2ff+U=; b=R/UUuhrfgvXJXjnQHRO7oqWycf4gwu1E6HgNrUcb1Rg7rKlhNyPPHflOBm6Z4rvPGZ 7dSJGRQU3pV8xkB2/rAU+tm1IL5e4wh00Vmsvihhk1jS12SMJEmHvF2ZnBY+RwylCjO6 /LEuEE+dqQ7jaJ/aVbFhQ8qnVngjBVB6E5LeGgl1ZLJ0Ikf84x/hqkRkVJhM1V4RFjNl KOG2PGuvn9nIzfH96WvXULY0Ho7guadoXGGbVEMtS2sauwUP3cut9iwRXd+QvD06TUj3 UQWU/fYOkYIXOF5qXCHZ3gTmdnvK8FiOmdhXAEGLDtaYE6P42Yoc5vcS5Sk8uHlBDSjq yMsA== 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=O+anphSYWu9Xsx3hQa2y8GzebJCXqq6ezQRrXI2ff+U=; b=jq35vQePbn1Ha1GTc8DRUpyGXpi2Oi++MXeIwg+o+ag8Edn/4xPWUho7dYakeL70HR PjwFJDjaiOnLlhXk25d7OhC46l/8LmOUT/6DLupwSqrdOP/RHRwBtoQa86dhfGn8dwHl +K7V6b59K/65zxU7YX+EQlLTDzK9A66F5jhqr/Os401bgPp17BwrTy//HjcL0O00/KXH wghVX5D2u9qV7BDTuGTUX0mvW3xY9P8LOyuJwlrXzLW8K8ojUt+aAITmL2wgKHGd81e4 5YiUcAfg/gI+o8a9BonmFLMXXqYkt5hBm+/EQdMY3LEjxLrVOl9gm3PCnJiRHnPtNBvD zBlQ== X-Gm-Message-State: AKaTC03WijBMTqmfYe+H/hWmMNLvWFiYcbgElb2pwDo6foR0HfurOrSzUGJfILoEj+j98g== X-Received: by 10.25.23.221 with SMTP id 90mr8669948lfx.34.1480355633479; Mon, 28 Nov 2016 09:53:53 -0800 (PST) Received: from [192.168.1.44] (ppp109-252-90-110.pppoe.spdop.ru. [109.252.90.110]) by smtp.gmail.com with ESMTPSA id z2sm13024189lja.10.2016.11.28.09.53.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 09:53:52 -0800 (PST) Subject: Re: [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services To: Daniel Kiper , grub-devel@gnu.org, xen-devel@lists.xenproject.org References: <1480020010-18421-1-git-send-email-daniel.kiper@oracle.com> <1480020010-18421-6-git-send-email-daniel.kiper@oracle.com> Cc: andrew.cooper3@citrix.com, eric.snowberg@oracle.com, jgross@suse.com, konrad.wilk@oracle.com, phcoder@gmail.com, seth.goldberg@oracle.com From: Andrei Borzenkov Message-ID: Date: Mon, 28 Nov 2016 20:53:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480020010-18421-6-git-send-email-daniel.kiper@oracle.com> Content-Type: text/plain; charset=windows-1251 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:c07::242 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 17:54:00 -0000 24.11.2016 23:40, Daniel Kiper пишет: > Signed-off-by: Daniel Kiper > --- > v2 - suggestions/fixes: > - clarify physical address meaning for EFI amd64 > mode with boot services enabled > (suggested by Andrew Cooper). > --- > doc/multiboot.texi | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++- > doc/multiboot2.h | 2 + > 2 files changed, 115 insertions(+), 2 deletions(-) > > diff --git a/doc/multiboot.texi b/doc/multiboot.texi > index f0f167e..cc1edab 100644 > --- a/doc/multiboot.texi > +++ b/doc/multiboot.texi > @@ -534,6 +534,66 @@ The physical address to which the boot loader should jump in order to > start running the operating system. > @end table > > +@subsection EFI i386 entry address tag of Multiboot2 header > + > +@example > +@group > + +-------------------+ > +u16 | type = 8 | > +u16 | flags | > +u32 | size | > +u_virt | entry_addr | > + +-------------------+ > +@end group > +@end example > + > +All of the address fields in this tag are physical addresses. Should not entry_addr be u_phys then? Otherwise what is exact difference between u_phys and u_virt? Also for type == 3? > +The meaning of each is as follows: > + > +@table @code > + > +@item entry_addr > +The physical address to which the boot loader should jump in order to > +start running EFI i386 compatible operating system code. > +@end table > + > +This tag is taken into account only on EFI i386 platforms > +when Multiboot2 image header contains EFI boot services tag. > +Then entry point specified in ELF header and the entry address > +tag of Multiboot2 header are ignored. > + > +@subsection EFI amd64 entry address tag of Multiboot2 header > + > +@example > +@group > + +-------------------+ > +u16 | type = 9 | > +u16 | flags | > +u32 | size | > +u_virt | entry_addr | > + +-------------------+ > +@end group > +@end example > + > +All of the address fields in this tag are physical addresses (paging > +mode is enabled and any memory space defined by the UEFI memory map > +is identity mapped, hence, virtual address equals physical address; Same here; it is confusing marking field as u_virt and describing it immediately as "physical address". > +Unified Extensible Firmware Interface Specification, Version 2.6, > +section 2.3.4, x64 Platforms, boot services). The meaning of each > +is as follows: > + > +@table @code > + > +@item entry_addr > +The physical address to which the boot loader should jump in order to > +start running EFI amd64 compatible operating system code. > +@end table > + > +This tag is taken into account only on EFI amd64 platforms > +when Multiboot2 image header contains EFI boot services tag. > +Then entry point specified in ELF header and the entry address > +tag of Multiboot2 header are ignored. > + Why do we have two different tags for what is effectively the same purpose? Is it possible for the same image to have both of them? Just for my understanding.