Re: [Xen-devel] [PATCH v2 24/41] arm : acpi create efi node for DOM0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.05.15 at 08:30, <parth.dixit@xxxxxxxxxx> wrote:
> On 20 May 2015 at 21:46, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 17.05.15 at 22:03, <parth.dixit@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel