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

[Parth Dixit <parth.dixit@xxxxxxxxxx>]

+shannon

On 26 May 2015 at 13:51, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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