From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v2 24/41] arm : acpi create efi node for DOM0 Date: Tue, 26 May 2015 09:21:04 +0100 Message-ID: <55644910020000780007DBDC@mail.emea.novell.com> References: <1431893048-5214-1-git-send-email-parth.dixit@linaro.org> <1431893048-5214-25-git-send-email-parth.dixit@linaro.org> <555CCF68020000780007C5EA@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Parth Dixit Cc: keir@xen.org, Ian Campbell , andrew.cooper3@citrix.com, tim@xen.org, xen-devel , Julien Grall , Stefano Stabellini , Christoffer Dall List-Id: xen-devel@lists.xenproject.org >>> On 24.05.15 at 08:30, wrote: > On 20 May 2015 at 21:46, Jan Beulich wrote: > >> >>> On 17.05.15 at 22:03, wrote: >> > --- a/xen/include/xen/efi.h >> > +++ b/xen/include/xen/efi.h >> > @@ -8,7 +8,7 @@ >> > extern const bool_t efi_enabled; >> > >> > #define EFI_INVALID_TABLE_ADDR (~0UL) >> > - >> > +#define EFI_MEM_DESC_V1 1 >> > /* Add fields here only if they need to be referenced from non-EFI >> code. */ >> > struct efi { >> > unsigned long mps; /* MPS table */ >> > @@ -20,6 +20,15 @@ struct efi { >> > >> > extern struct efi efi; >> > >> > +struct efi_memory_desc { >> > + u32 type; >> > + u32 pad; >> > + u64 phys_addr; >> > + u64 virt_addr; >> > + u64 num_pages; >> > + u64 attribute; >> > +}; >> > + >> > #ifndef __ASSEMBLY__ >> > >> > union xenpf_efi_info; >> >> NAK - you're supposed to use what is already there, or give a good >> reason why redundant declarations are needed. >> >> I thought efi fields that need to be refreneced from non-efi code can be > added here. > Is this not correct? > Although i am rethinking about the design so that efi tables are extracted > in the common efi code and passed > to non efi code as it is done in case of device tree. I'll post rfc for > that would that be okay? At the first glance this would seem to be the right approach. Btw - please correct your reply style such that it is immediately clear which parts comprise your response and which parts are what you respond to (you have a misguiding > on the first line of your reply text here as well as in the reply to 02/41). Jan