Re: [Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions

2015-07-30 Thread Parth Dixit
On 31 July 2015 at 00:01, Julien Grall  wrote:
> Hi,
>
> On 30/07/15 19:02, Parth Dixit wrote:
>> instead of getting mmio information for individual
>> devices from dsdt, we will map all the non-ram regions described in
>> uefi. AML interpreter option was discussed earlier and it was decided
>> not to go with that approach. You can find more details in the linaro
>> xen wiki for the reasoning behind it.
>
> Which page are you talking about? I only found [1] speaking about ACPI.
> Although, there is nothing related to MMIO mapping.
I was talking about the reasons for not using aml interpreter in xen.
> Anyway, it's not possible to get the list of MMIOs regions for the UEFI
> System Memory Map (see the mail you forward on the ML [2]).
> Although, based on the RAM region we could deduce a possible set of MMIO
> regions. It would be fine to mapped unused region in memory and we could
> take advantage of super page.
>
> While you are speaking about the wiki page. Can one of you update the
> wiki page about the boot protocol? Jan had some concerns about the
> solution you choose (see [3] to not mention the whole thread).
>
> We need to agree on the boot protocol before going further on this series.
>
> To speed up the upstreaming process, it would be nice if you start a
> thread about the boot protocol for ACPI with relevant people in CCed.
> The main goal will be to explain why you choose this way. This will be
> the base to talk about improvement and/or answer concerns for other people.
>
> FWIW, Jan also suggested a different boot protocol based on the x86 one.
> It may be good for you to see whether it would fit ACPI on ARM.
>
> Regards,
>
> [1] https://wiki.linaro.org/LEG/Engineering/Virtualization/ACPI_on_Xen
>
> [2]
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02059.html
>
> [3] http://lists.xen.org/archives/html/xen-devel/2015-05/msg02736.html
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions

2015-07-30 Thread Parth Dixit
Hi Shannon,
instead of getting mmio information for individual
devices from dsdt, we will map all the non-ram regions described in
uefi. AML interpreter option was discussed earlier and it was decided
not to go with that approach. You can find more details in the linaro
xen wiki for the reasoning behind it.

regards
parth

On 30 July 2015 at 17:49, Shannon Zhao  wrote:
>
>
> On 2015/7/5 21:30, Parth Dixit wrote:
>> +shannon
>>
>> On 15 June 2015 at 06:49, Julien Grall  wrote:
>>> Hi Parth,
>>>
>>> On 14/06/2015 11:27, Parth Dixit wrote:
>>>>
>>>> On 8 June 2015 at 22:20, Julien Grall  wrote:
>>>>>
>>>>> Hi Parth,
>>>>>
>>>>> On 17/05/2015 21:03, Parth Dixit wrote:
>>>>>>
>>>>>>
>>>>>> In ACPI mmio regions are described in DSDT which requires
>>>>>> AML interpreter. Defer the mapping of mmio until DSDT is parsed in
>>>>>> DOM0 and map mmio's dynamically at the time of request.
>>>>>
>>>>>
>>>>>
>>>>> I'm against a such solution. Even though it's DOM0 we should avoid to
>>>>> allow
>>>>> him to map anything (RAM,...) on data abort.
>>>>
>>>> I think we agreed to this solution
>>>> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02059.html
>>>
>>>
>>> Firstly, this kind of link should have been put in the changelog of the
>>> patch (after ---). It helps the reviewer to know what was decided (or not)
>>> on the previous discussion. It's more true with a series of more than 40
>>> patches...
>>>
>>> Secondly, the thread you pointed as some discussion on it but no formal
>>> agreement about what to do. If there is no answer, it's better to do a
>>> resume and ask if anyone are agree.
>>>
>>> Finally, what you've implemented and what was suggested by Ian is different.
>>> You are allowing any region to be mapped in DOM0 via this way. Only MMIO
>>> should be allowed.
>>>
>>> Concerning the mapping attribute used. Based on Ard answer "The UEFI spec
>>> mandates that the memory map describes all memory in the system, so if dom0
>>> accesses any ranges outside of that, it makes sense
>>> to just use device mappings for stage 2.". We should use by default Device
>>> Stage 2, it's safer. If it doesn't work later (because some PCI BAR may be
>>> memory, which if I wasn't able to prove), then we can think differently.
>>>
>>> For the mapping of the MMIO to DOM0, I believe we can map any non-RAM (and
>>> any non-RAM not used by Xen) regions to DOM0 at boot time (I think x86 does
>>> that). It would keep the ACPI code contained at boot time and no difference
>>> during runtime.
>>>
>
> But How do we get the MMIO information of the devices in DSDT table? If
> we want to parse DSDT table, we must introduce AML interpreter, IIUC.
>
> Julien, do you have any other ideas?
>
> Thanks,
> --
> Shannon

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


Re: [Xen-devel] [PATCH v2 01/41] arm/acpi: Build numa for x86 only

2015-07-05 Thread Parth Dixit
On 5 July 2015 at 23:09, Julien Grall  wrote:
> Hi,
>
> On 05/07/2015 13:59, Parth Dixit wrote:
>>
>> +shannon
>
>
> I've just received ~50 mails "+shannon". Couldn't you have forward all the
> email privately rather replying to every single mail and cc shannon?
I thought about FWD'ing initially but thought it would be better to CC
, in case he has any questions he can continue with the same mail
chain and others would also be aware that he is working on it
otherwise it may lead to confusion.
Sorry for the trouble..
> Archives also exists for Xen devel, and it's even possible to  download them
> in order to answer to the mail
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 41/41] arm : acpi route irq's at time of boot

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 23:14, Julien Grall  wrote:
> Hi,
>
> On 17/05/2015 21:04, Parth Dixit wrote:
>>
>> NOTE: This is a wrokaround to be fixed later.
>
>
> How do you plan to fix it?
>
>> Route all the irq's to Dom0 at the time of booting.
>> Trigger and polarity will be set dyanmaically when
>
>
> s/dyanmaically/dynamically/
>
>> Dom0 request's for it.
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>   xen/arch/arm/domain_build.c | 20 
>>   1 file changed, 20 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 2ce30bf..cdad86b 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1481,6 +1481,26 @@ static int prepare_acpi(struct domain *d, struct
>> kernel_info *kinfo, struct memb
>>   acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp) );
>>
>>   prepare_efi_table(d, kinfo, tbl_add);
>> +
>> +/* configure interrupts gicv2 only */
>
>
> The indentation seems wrong.
>
> Also, why GICv2 only? I don't see anything GICv2 specific...
>
>> + for( i = 32 ; i < 255 ; i++ )
>> + {
>> +struct irq_desc *desc;
>
>
> Newline.
>
>> +desc = irq_to_desc(i);
>> +if( desc->action != NULL)
>> +continue;
>> +
>> +vgic_reserve_virq(d, i);
>
>
> This function returns an error code. If you don't use it explain why in a
> comment.
>
>> +set_irq_type(i, ACPI_IRQ_TYPE_NONE);
>> +res = route_irq_to_guest(d, i, i, NULL);
>> +if ( res )
>> +{
>> +printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
>> +i, d->domain_id);
>> +continue;
>
>
> Shouldn't we bail out here?
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 40/41] xen: arm64: Add ACPI support

2015-07-05 Thread Parth Dixit
+shannon

On 18 May 2015 at 01:34, Parth Dixit  wrote:
> From: Naresh Bhat 
>
> Add ACPI support on arm64 xen hypervisor.
>
> Signed-off-by: Naresh Bhat 
> ---
>  config/arm64.mk  | 1 +
>  xen/include/asm-arm/config.h | 5 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/config/arm64.mk b/config/arm64.mk
> index e24c1d1..bce9107 100644
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -10,6 +10,7 @@ HAS_PL011 := y
>  HAS_CADENCE_UART := y
>  HAS_NS16550 := y
>  HAS_MEM_ACCESS := y
> +HAS_ACPI := y
>
>  # Use only if calling $(LD) directly.
>  LDFLAGS_DIRECT += -EL
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 3b23e05..0170925 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -33,6 +33,11 @@
>
>  #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
>
> +#if defined(CONFIG_ARM_64)
> +#define CONFIG_ACPI 1
> +#define CONFIG_ACPI_BOOT 1
> +#endif
> +
>  #define CONFIG_SMP 1
>
>  #define CONFIG_VIDEO 1
> --
> 1.9.1
>

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


Re: [Xen-devel] [PATCH v2 39/41] arm : acpi configure interrupts dynamically

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 23:09, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/2015 21:04, Parth Dixit wrote:
>>
>> Interrupt information is described in DSDT and is not available at
>> the time of booting. Configure the interrupts dynamically when requested
>> by Dom0
>
>
> Missing "."
>
> Also, I'm sure we talked about it multiple time. I'd like to keep the ACPI
> changes very contained to Xen boot. Your change is not ACPI specific and
> could be used for DT.
>
>
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>   xen/arch/arm/vgic.c | 18 ++
>>   1 file changed, 18 insertions(+)
>>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 73a6f7e..f63deb4 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -25,6 +25,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>
>>   #include 
>>
>> @@ -285,6 +286,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int
>> n)
>>   }
>>   }
>>
>> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
>> +
>>   void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>>   {
>>   struct domain *d = v->domain;
>> @@ -296,7 +299,22 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int
>> n)
>>   struct vcpu *v_target;
>>
>>   while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>> +#ifdef CONFIG_ACPI
>> +struct vgic_irq_rank *vr = vgic_get_rank(v, n);
>> +uint32_t tr;
>
>
> New line.
>
>> +irq = i + (32 * n);
>> +if( ( !acpi_disabled ) && ( n != 0 ) && is_hardware_domain(d) )
>
>
> You need to add a comment explaining the ( n != 0 ) i.e we don't SGIs and
> PPIs are RO. It's implementation defined for PPI but it's preferable to let
> Xen take care of it.
>
> Also, we should set the type only for IRQ assigned to DOM0 (i.e p->desc !=
> NULL). With your current solution, DOM0 may change the configuration of the
> serial IRQ by mistake and take down Xen because the physical IRQ is enabled
> and the behavior will be unpredictable.
>
> Furthermore, during passthrough, the IRQ may not have been configured by
> DOM0. So we have to let the guest configure the IRQ.
>
>> +{
>> +tr = vr->icfg[i >> 4] ;
>> +
>> +if( ( tr & VGIC_ICFG_MASK(i) ) )
>> +set_irq_type(irq, ACPI_IRQ_TYPE_EDGE_BOTH);
>> +else
>> +set_irq_type(irq, ACPI_IRQ_TYPE_LEVEL_MASK);
>
>
> Given that only SPI can be configured it would have been better to call
> irq_set_type.
>
> Although, those 2 functions don't do what you think. They are setting the
> type internally in Xen but don't change the GIC interrupt configuration
> register.
>
> Lastly, they may fail because the configuration as been set earlier (as you
> did in patch #41.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 38/41] arm : acpi enable efi for acpi

2015-07-05 Thread Parth Dixit
+shannon

On 20 May 2015 at 21:57, Jan Beulich  wrote:
 On 17.05.15 at 22:04,  wrote:
>> @@ -104,6 +105,7 @@ static void __init parse_acpi_param(char *s)
>>  else if ( !strcmp(s, "force") )
>>  {
>>  acpi_disabled = 0;
>> +efi_enabled = 1;
>
> What has "acpi=force" to do with EFI?
>
>> --- a/xen/include/xen/efi.h
>> +++ b/xen/include/xen/efi.h
>> @@ -5,7 +5,7 @@
>>  #include 
>>  #endif
>>
>> -extern const bool_t efi_enabled;
>> +extern bool_t efi_enabled;
>
> Doesn't this break the x86 build?
>
> Jan
>

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


Re: [Xen-devel] [PATCH v2 36/41] arm : acpi pass rsdp and memory via efi table

2015-07-05 Thread Parth Dixit
+shannon

On 18 May 2015 at 01:34, Parth Dixit  wrote:
> Create EFI table and populate it with DOM0 memory and address
> of RSDP. Fix device tree with correct addresses of EFI table
> and start of memory descriptor address.
>
> Signed-off-by: Parth Dixit 
> ---
>  xen/arch/arm/domain_build.c | 106 
> 
>  1 file changed, 106 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 0ad70c1..2ce30bf 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1260,6 +1260,111 @@ static uint32_t xz_crc32(uint8_t *buf, size_t size, 
> uint32_t crc)
> return ~crc;
>  }
>
> +static int prepare_efi_table(struct domain *d,
> +  const struct kernel_info *kinfo,
> +   struct membank tbl_add[])
> +{
> +u64 fdt_val64;
> +u32 fdt_val32;
> +int size;
> +int i,offset;
> +unsigned long res;
> +int node;
> +u16 *fw_vendor;
> +u8 *base_ptr;
> +struct efi_memory_desc *memory_map;
> +struct efi_config_table *acpi_ect;
> +struct efi_system_table *sys_tbl;
> +void * __user tbl_virt = (void * __user)(register_t)kinfo->acpi_paddr;
> +struct efi_system_table *efi_sys_tbl = ( struct efi_system_table *)
> +maddr_to_virt(efi.est);
> +
> +xz_crc32_init();
> +/* Fix up linux,uefi-system-table and linux,mmap-size in /chosen */
> +node = fdt_path_offset(kinfo->fdt, "/chosen");
> +if ( node < 0 )
> +panic("Cannot find the /chosen node");
> +
> +size = tbl_add[TBL_EFIT].size
> ++  tbl_add[TBL_MMAP].size;
> +
> +tbl_virt += get_acpi_size();
> +base_ptr = xzalloc_bytes(size);
> +sys_tbl = (struct efi_system_table *)base_ptr;
> +memcpy( (struct efi_table_hdr*)&(sys_tbl->hdr),
> +(struct efi_table_hdr*)&(efi_sys_tbl->hdr),
> +sizeof(struct efi_table_hdr) );
> +sys_tbl->hdr.headersize = tbl_add[TBL_EFIT].size;
> +
> +sys_tbl->fw_revision = efi_sys_tbl->fw_revision;
> +sys_tbl->nr_tables = 1;
> +fdt_val64 = cpu_to_fdt64((u64)(uintptr_t)tbl_virt);
> +res = fdt_setprop_inplace(kinfo->fdt, node, "linux,uefi-system-table",
> +  &fdt_val64, sizeof(fdt_val64));
> +if ( res )
> +return res;
> +offset = sizeof(struct efi_system_table);
> +
> +size = sizeof(XEN_EFI_FW_VENDOR);
> +fw_vendor = (u16 *)(base_ptr+offset);
> +memcpy(fw_vendor, XEN_EFI_FW_VENDOR, size);
> +sys_tbl->fw_vendor = (u64)(tbl_virt+offset);
> +offset+=size;
> +
> +size = sizeof(struct efi_config_table);
> +acpi_ect = (struct efi_config_table *)(base_ptr+offset);
> +acpi_ect->guid = ACPI_20_TBL_GUID;
> +acpi_ect->table = efi.acpi20;
> +sys_tbl->tables = (u64)(tbl_virt+offset);
> +offset += size;
> +sys_tbl->hdr.crc32 = xz_crc32((uint8_t *)sys_tbl, 
> sys_tbl->hdr.headersize, 0);
> +
> +size = tbl_add[TBL_MMAP].size;
> +memory_map = (struct efi_memory_desc *)(base_ptr+offset);
> +fdt_val64 = cpu_to_fdt64((u64)(uintptr_t)(tbl_virt+offset));
> +res = fdt_setprop_inplace(kinfo->fdt, node, "linux,uefi-mmap-start",
> +  &fdt_val64,  sizeof(fdt_val64));
> +if ( res )
> +return res;
> +
> +fdt_val32 = cpu_to_fdt32(size);
> +res = fdt_setprop_inplace(kinfo->fdt, node, "linux,uefi-mmap-size",
> +  &fdt_val32,  sizeof(fdt_val32));
> +size += offset;
> +
> +for( i=0; i < kinfo->mem.nr_banks ; i++)
> +{
> +memory_map[i].type = EFI_CONVENTIONAL_MEMORY;
> +memory_map[i].phys_addr = kinfo->mem.bank[i].start;
> +memory_map[i].num_pages = kinfo->mem.bank[i].size/PAGE_SIZE;
> +memory_map[i].attribute |= EFI_MEMORY_ATT_WB;
> +}
> +offset = kinfo->mem.nr_banks;
> +for( i=0; i < acpi_mem.nr_banks ; i++,offset++)
> +{
> +memory_map[offset].type = EFI_ACPI_RECLAIM_MEMORY;
> +memory_map[offset].phys_addr = acpi_mem.bank[i].start;
> +memory_map[offset].num_pages = acpi_mem.bank[i].size/PAGE_SIZE;
> +}
> +
> +for( i=0; i < TBL_MMAX; i++, offset++ )
> +{
> +memory_map[offset].type = EFI_ACPI_RECLAIM_MEMORY;
> +memory_map[offset].phys_addr = tbl_add[i].start;
> +memory_map[offset].num_pages =tbl_add[i].size/PAGE_SIZE;
> +memory_map[i].attribute |= EFI_MEMORY_ATT_WB;
> +}
> +
> +res = raw_copy_to_gues

Re: [Xen-devel] [PATCH v2 35/41] arm : acpi add helper function to calculate crc32

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 22:29, Julien Grall  wrote:
> Hi,
>
> On 17/05/2015 21:04, Parth Dixit wrote:
>>
>> Add helper functions for calculating crc32.
>> This is required for computing crc of efi table.
>> These functions are copied from here
>> http://mirrors.neusoft.edu.cn/rpi-kernel/lib/xz/xz_crc32.c
>> Original author's are  Lasse Collin and Igor Pavlov.
>
>
> I'm nearly sure this patch will break compilation during bisection...
>
> Anyway, the function xz_crc32_* already exist in the tree. Please use them.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 34/41] arm : acpi create and map acpi tables

2015-07-05 Thread Parth Dixit
+shannon

On 18 May 2015 at 01:34, Parth Dixit  wrote:
> XSDT table cannot be passed as is to DOM0 because xen creates additional
> tables which have to be added to XSDT table entry.
> Copy existing XSDT and modify table to add new entries.
> Create status override table,xen environment table.
> Copy the tables to DOM0 memory.
>
> Signed-off-by: Parth Dixit 
> ---
>  xen/arch/arm/domain_build.c | 108 
> 
>  1 file changed, 108 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 90bdd01..36b072b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1225,16 +1226,123 @@ static int handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  return res;
>  }
>  #ifdef CONFIG_ACPI
> +
> +static int create_xen_acpi_tables(struct kernel_info *kinfo, struct domain 
> *d,
> +  struct membank tbl_add[])
> +{
> +unsigned long res;
> +int offset=0;
> +u64 size;
> +u8 checksum;
> +u64 *table_entry;
> +u64 addr;
> +u8 *base_ptr;
> +struct acpi_table_xenv *xenv=NULL;
> +struct acpi_table_stao *stao=NULL;
> +struct acpi_table_header *table;
> +void * __user tbl_virt = (void * __user)(register_t)kinfo->acpi_paddr;
> +
> +set_acpi_size(0);
> +addr = tbl_add[TBL_XSDT].start;
> +size = tbl_add[TBL_XSDT].size
> +   - ( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
> +
> +table = acpi_os_map_memory(addr, size);
> +size =   tbl_add[TBL_XSDT].size
> +  +  tbl_add[TBL_XENV].size
> +  +  tbl_add[TBL_STAO].size;
> +
> +base_ptr = xzalloc_bytes(size);
> +if( base_ptr == NULL)
> +return -ENOMEM;
> +
> +res = vgic_allocate_ppi(d);
> +if ( res < 0 )
> +panic("Unable to allocate a PPI for the event channel interrupt\n");
> +
> +d->arch.evtchn_irq = res;
> +
> +printk("Allocating PPI %u for event channel interrupt\n",
> +   d->arch.evtchn_irq);
> +
> +   /* add xen env table */
> +tbl_add[TBL_XENV].start =(u64)(base_ptr);
> +xenv = (struct acpi_table_xenv *)(tbl_add[TBL_XENV].start);
> +ACPI_MEMCPY((void *)xenv, table, sizeof(struct acpi_table_header));
> +ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
> +xenv->header.length = tbl_add[TBL_XENV].size;
> +ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
> +xenv->header.revision = 1;
> +xenv->gnt_start = 0x001000;
> +xenv->gnt_size = 0x2;
> +xenv->evt_intr = d->arch.evtchn_irq;
> +xenv->evt_intr_flag = ( 0xff & EVT_CHN_INTR_TRIG );
> +checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), 
> tbl_add[TBL_XENV].size);
> +xenv->header.checksum = xenv->header.checksum - checksum;
> +tbl_add[TBL_XENV].start = (u64)(tbl_virt);
> +offset += tbl_add[TBL_XENV].size;
> +
> +/* add stao table */
> +tbl_add[TBL_STAO].start =(u64)(base_ptr+offset);
> +stao = (struct acpi_table_stao *)(tbl_add[TBL_STAO].start);
> +ACPI_MEMCPY((void *)stao, table, sizeof(struct acpi_table_header));
> +ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);
> +stao->header.length = tbl_add[TBL_STAO].size;
> +stao->uart = 1;
> +checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), 
> tbl_add[TBL_STAO].size);
> +stao->header.checksum = stao->header.checksum - checksum;
> +tbl_add[TBL_STAO].start =(u64) (tbl_virt+offset);
> +offset += tbl_add[TBL_STAO].size;
> +
> +/* fix xsdt table */
> +ACPI_MEMCPY(base_ptr+offset, table,table->length);
> +acpi_os_unmap_memory(table, table->length);
> +
> +table = (struct acpi_table_header *)(base_ptr+offset);
> +table->length = tbl_add[TBL_XSDT].size;
> +table_entry = ACPI_CAST_PTR(u64,
> +(base_ptr+offset + sizeof(struct 
> acpi_table_header) ) );
> +table_entry +=
> +( ( (table->length - sizeof(struct acpi_table_header) ) /
> +sizeof(acpi_native_uint) ) );
> +
> +table_entry--;
> +*table_entry = tbl_add[TBL_XENV].start ;
> +
> +table_entry--;
> +*table_entry = tbl_add[TBL_STAO].start;
> +
> +checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
> +table->checksum =  table->checksum - checksum;
> +tbl_add[TBL_XSDT].start =(u64)(tbl_virt+offset);
> +
> +res = raw_copy_to_guest_

Re: [Xen-devel] [PATCH v2 33/41] arm : acpi prepare acpi tables for dom0

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 22:24, Julien Grall  wrote:
>
>
> On 17/05/2015 21:04, Parth Dixit wrote:
>>
>> Map acpi tables described in uefi table to DOM0 address space
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>   xen/arch/arm/domain_build.c | 59
>> -
>>   1 file changed, 58 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index f2ca525..90bdd01 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1225,6 +1225,50 @@ static int handle_node(struct domain *d, struct
>> kernel_info *kinfo,
>>   return res;
>>   }
>>   #ifdef CONFIG_ACPI
>> +static int prepare_acpi(struct domain *d, struct kernel_info *kinfo,
>> struct membank tbl_add[])
>> +{
>> +unsigned long res;
>> +u64 addr, size;
>> +int i = 0;
>> +
>> +addr = acpi_os_get_root_pointer();
>> +if( !addr )
>> +return -ENODEV;
>> +
>> +size = sizeof(struct acpi_table_rsdp);
>> +
>> +res = map_regions(d,
>> +  paddr_to_pfn(addr & PAGE_MASK),
>> +  DIV_ROUND_UP(size, PAGE_SIZE),
>> +  paddr_to_pfn(addr & PAGE_MASK));
>> +if ( res )
>> +{
>> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
>> +" - 0x%"PRIx64" in domain \n",
>> +addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
>> + return res;
>> +}
>> +
>> +for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
>
>
> The description of the patch suggest that you will use acpi_mem introduced
> in patch #29 but you are using acpi_glb_root_table_list.
>
> Please either update the commit message or change the loop.
>
> IHMO, the latter would be cleaner.
>
>
>> +{
>> +addr = acpi_gbl_root_table_list.tables[i].address;
>> +size = acpi_gbl_root_table_list.tables[i].length;
>> +res = map_regions(d,
>> +  paddr_to_pfn(addr & PAGE_MASK),
>> +  DIV_ROUND_UP(size, PAGE_SIZE),
>> +  paddr_to_pfn(addr & PAGE_MASK));
>> +if ( res )
>> +{
>> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
>> +" - 0x%"PRIx64" in domain \n",
>> +addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
>> + return res;
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>>   static int estimate_acpi_size(struct domain *d,struct kernel_info
>> *kinfo, struct membank tbl_add[])
>>   {
>>   int size = 0;
>> @@ -1429,6 +1473,10 @@ static int create_acpi_dtb(struct domain *d, struct
>> kernel_info *kinfo, struct m
>>   {
>>   return -EINVAL;
>>   }
>> +static int prepare_acpi(struct domain *d, struct kernel_info *kinfo,
>> struct membank tbl_add[])
>> +{
>
> BUG();
>
>> +return -EINVAL;
>> +}
>>   #endif
>>   static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
>>   {
>> @@ -1647,10 +1695,19 @@ int construct_dom0(struct domain *d)
>>* as the initrd & fdt in RAM, so call it first.
>>*/
>>   kernel_load(&kinfo);
>> +
>> +if ( !acpi_disabled )
>> +{
>> +rc = prepare_acpi(d, &kinfo, tbl_add);
>> +if ( rc < 0 )
>> +return rc;
>> +}
>> +
>>   /* initrd_load will fix up the fdt, so call it before dtb_load */
>>   initrd_load(&kinfo);
>>   /* Allocate the event channel IRQ and fix up the device tree */
>> -evtchn_fixup(d, &kinfo);
>> +if( acpi_disabled )
>> +evtchn_fixup(d, &kinfo);
>
>
> This change doesn't belong to this patch.
>
>>   dtb_load(&kinfo);
>>
>>   /* Now that we are done restore the original p2m and current. */
>>
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions

2015-07-05 Thread Parth Dixit
+shannon

On 15 June 2015 at 06:49, Julien Grall  wrote:
> Hi Parth,
>
> On 14/06/2015 11:27, Parth Dixit wrote:
>>
>> On 8 June 2015 at 22:20, Julien Grall  wrote:
>>>
>>> Hi Parth,
>>>
>>> On 17/05/2015 21:03, Parth Dixit wrote:
>>>>
>>>>
>>>> In ACPI mmio regions are described in DSDT which requires
>>>> AML interpreter. Defer the mapping of mmio until DSDT is parsed in
>>>> DOM0 and map mmio's dynamically at the time of request.
>>>
>>>
>>>
>>> I'm against a such solution. Even though it's DOM0 we should avoid to
>>> allow
>>> him to map anything (RAM,...) on data abort.
>>
>> I think we agreed to this solution
>> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02059.html
>
>
> Firstly, this kind of link should have been put in the changelog of the
> patch (after ---). It helps the reviewer to know what was decided (or not)
> on the previous discussion. It's more true with a series of more than 40
> patches...
>
> Secondly, the thread you pointed as some discussion on it but no formal
> agreement about what to do. If there is no answer, it's better to do a
> resume and ask if anyone are agree.
>
> Finally, what you've implemented and what was suggested by Ian is different.
> You are allowing any region to be mapped in DOM0 via this way. Only MMIO
> should be allowed.
>
> Concerning the mapping attribute used. Based on Ard answer "The UEFI spec
> mandates that the memory map describes all memory in the system, so if dom0
> accesses any ranges outside of that, it makes sense
> to just use device mappings for stage 2.". We should use by default Device
> Stage 2, it's safer. If it doesn't work later (because some PCI BAR may be
> memory, which if I wasn't able to prove), then we can think differently.
>
> For the mapping of the MMIO to DOM0, I believe we can map any non-RAM (and
> any non-RAM not used by Xen) regions to DOM0 at boot time (I think x86 does
> that). It would keep the ACPI code contained at boot time and no difference
> during runtime.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 31/41] arm : acpi estimate memory required for acpi/efi tables

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 22:14, Julien Grall  wrote:
> Hi Parth,
>
> I think it misses a ":" between acpi and estimate.
>
> On 17/05/2015 21:03, Parth Dixit wrote:
>>
>> Estimate the memory required for loading acpi/efi tablee
>> in DOM0. Initialize the size of acpi/efi tables.
>
>
> It needs more description...
>
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>   xen/arch/arm/domain_build.c | 54
>> -
>>   1 file changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 9d98f64..f2ca525 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -69,6 +69,9 @@ struct meminfo __initdata acpi_mem;
>>   #ifdef CONFIG_ACPI
>>   /* Reserve DOM0 FDT size in ACPI case only */
>>   #define DOM0_FDT_MIN_SIZE 4096
>> +#define NR_NEW_XEN_TABLES 2
>
>
> New table of what?
>
>> +/* Constant to indicate "Xen" in unicode u16 format */
>> +static const u16 XEN_EFI_FW_VENDOR[] ={0x0058,0x0065,0x006E,0x};
>
>
> I think you have to rework the order of your patch in this series. This kind
> of variable should appear where you add the EFI table and not where you
> estimate the size.
>
> It would be easier to understand what it's used for.
>
>
>>   #endif
>>
>>   struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
>> @@ -1222,6 +1225,51 @@ static int handle_node(struct domain *d, struct
>> kernel_info *kinfo,
>>   return res;
>>   }
>>   #ifdef CONFIG_ACPI
>> +static int estimate_acpi_size(struct domain *d,struct kernel_info *kinfo,
>> struct membank tbl_add[])
>> +{
>> +int size = 0;
>> +u64 addr;
>> +struct acpi_table_header *table;
>> +struct acpi_table_rsdp *rsdp_tbl;
>> +
>> +set_acpi_size(size);
>> +tbl_add[TBL_EFIT].size = sizeof(struct efi_system_table)
>> ++ sizeof(struct efi_config_table)
>> ++ sizeof(XEN_EFI_FW_VENDOR);
>> +
>> +tbl_add[TBL_MMAP].size = sizeof(struct efi_memory_desc)
>> +*(kinfo->mem.nr_banks + acpi_mem.nr_banks + TBL_MMAX);
>> +tbl_add[TBL_XENV].size = sizeof(struct acpi_table_xenv);
>> +tbl_add[TBL_STAO].size = sizeof(struct acpi_table_stao);
>> +
>> +addr = acpi_os_get_root_pointer();
>> +if( !addr )
>> +return -ENODEV;
>> +
>> +rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
>> +if( !rsdp_tbl )
>> +return -ENOMEM;
>> +
>> +table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
>> +   sizeof(struct acpi_table_header));
>> +if ( !table )
>> +return -ENOMEM;
>> +
>> +tbl_add[TBL_XSDT].size = table->length
>> ++( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
>
>
> Coding style:
>
> + (NR_NEW_XEN_TABLES * sizeof(acpi_native_uint);
>
> This is also needs some explanation of the acpi_native_uint. We should be
> able to understand the code without have to search on the web. A reference
> to the doc would works too...
>
>> +tbl_add[TBL_XSDT].start = rsdp_tbl->xsdt_physical_address;
>> +acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
>> +acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
>> +size = tbl_add[TBL_EFIT].size
>
>
> The size is used to set acpi_size but this is EFI table... Please be
> consistent.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 30/41] arm : acpi add placeholder for acpi load address

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 21:49, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/2015 21:03, Parth Dixit wrote:
>>
>> EFI table, memory description table and some of acpi tables
>> will reside in DOM0 memory. Add placeholder for starting
>> address for loading in DOM0 and get/set acpi size helpers.
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>   xen/arch/arm/acpi/lib.c| 12 
>>   xen/arch/arm/kernel.c  |  5 -
>>   xen/arch/arm/kernel.h  |  1 +
>>   xen/include/asm-arm/acpi.h |  4 
>>   4 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
>> index fd9bfa4..9b9f059 100644
>> --- a/xen/arch/arm/acpi/lib.c
>> +++ b/xen/arch/arm/acpi/lib.c
>> @@ -1,6 +1,8 @@
>>   #include 
>>   #include 
>>
>> +static int acpi_len = 0;
>> +
>
>
> There is no reason to type this variable signed int. Please use unsigned
> int.
>
> Even better, paddr_t as you use like that after.
>
>>   void __iomem *
>>   acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>>   {
>> @@ -17,3 +19,13 @@ inline bool_t acpi_psci_hvc_present(void)
>>   {
>>   return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
>>   }
>> +
>> +inline int get_acpi_size(void)
>> +{
>> +return acpi_len;
>> +}
>> +
>> +inline void set_acpi_size(int size)
>> +{
>> +acpi_len = size;
>> +}
>
>
> The variable name is misleading, acpi_len doesn't correspond to the real
> size of the ACPI but only whole size of the table generated by Xen.
>
> Furthermore, based the usage I was able to find within the other patch, this
> variable is only used during dom0 creation and should live in kinfo.
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 29/41] arm : acpi read acpi memory info from uefi

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 21:39, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/2015 21:03, Parth Dixit wrote:
>>
>> ACPI memory is seperate from conventional memory and should
>
>
> s/seperate/separate/
>
>> be marked as reserved while passing to DOM0. Create a new meminfo
>> structure to store all the acpi tables listed in uefi.
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>   xen/arch/arm/domain_build.c |  2 ++
>>   xen/arch/arm/efi/efi-boot.h | 20 +---
>>   xen/include/asm-arm/setup.h |  1 +
>>   3 files changed, 20 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 865b81a..9d98f64 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -42,6 +42,8 @@ static void __init parse_dom0_mem(const char *s)
>>   }
>>   custom_param("dom0_mem", parse_dom0_mem);
>>
>> +struct meminfo __initdata acpi_mem;
>> +
>
>
> Please protect it with an CONFIG_ACPI and please keep all the ACPI variable
> in the same place within this file.
>
>
>>   //#define DEBUG_DT
>>
>>   #ifdef DEBUG_DT
>> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
>> index b02cc02..d21cba5 100644
>> --- a/xen/arch/arm/efi/efi-boot.h
>> +++ b/xen/arch/arm/efi/efi-boot.h
>> @@ -127,14 +127,16 @@ static EFI_STATUS __init
>> efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
>>   {
>>   int Index;
>>   int i = 0;
>> +int j = 0;
>>   EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
>>
>>   for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
>>   {
>> -if ( desc_ptr->Type == EfiConventionalMemory
>> - || desc_ptr->Type == EfiBootServicesCode
>> - || desc_ptr->Type == EfiBootServicesData )
>> +switch( desc_ptr->Type )
>>   {
>> +case EfiConventionalMemory:
>> +case EfiBootServicesCode:
>> +case EfiBootServicesData:
>>   if ( i >= NR_MEM_BANKS )
>>   {
>>   PrintStr(L"Warning: All " __stringify(NR_MEM_BANKS)
>> @@ -144,11 +146,23 @@ static EFI_STATUS __init
>> efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
>>   bootinfo.mem.bank[i].start = desc_ptr->PhysicalStart;
>>   bootinfo.mem.bank[i].size = desc_ptr->NumberOfPages *
>> EFI_PAGE_SIZE;
>>   ++i;
>> +break;
>
>
> #ifdef CONFIG_ACPI
>
>> +case EfiACPIReclaimMemory:
>> +if ( j >= NR_MEM_BANKS )
>> +{
>> +PrintStr(L"Warning: All " __stringify(NR_MEM_BANKS)
>> +  " acpi meminfo mem banks exhausted.\r\n");
>
>
> DOM0 will likely fail to boot if one of the ACPI region is not present
> because there is not enough place in the array.
>
> Either you allocate dynamically the array or you stop booting on the
> platform. But a warning is not enough...
>
>> +break;
>> +}
>> +acpi_mem.bank[j].start = desc_ptr->PhysicalStart;
>> +acpi_mem.bank[j].size  = desc_ptr->NumberOfPages *
>> EFI_PAGE_SIZE;
>> +++j;
>>   }
>>   desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
>>   }
>>
>>   bootinfo.mem.nr_banks = i;
>> +acpi_mem.nr_banks = j;
>>   return EFI_SUCCESS;
>>   }
>>
>> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
>> index ba5a67d..1865b72 100644
>> --- a/xen/include/asm-arm/setup.h
>> +++ b/xen/include/asm-arm/setup.h
>> @@ -46,6 +46,7 @@ struct bootinfo {
>>   };
>>
>>   extern struct bootinfo bootinfo;
>> +extern struct meminfo acpi_mem;
>
>
> #ifdef CONFIG_ACPI
> ...
> #endif
>
>>
>>   void arch_init_memory(void);
>>
>>
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 28/41] arm : acpi add efi structures to common efi header

2015-07-05 Thread Parth Dixit
+shannon

On 20 May 2015 at 21:55, Jan Beulich  wrote:
 On 17.05.15 at 22:03,  wrote:
>> add efi table and memory descriptor structures
>> to common efi header file and pass efi system table address
>> retrieved from uefi.This is required for
>> creating efi table and passing memory information
>> to DOM0
>
> I may be missing some background here, but from a conceptional
> pov I don't buy any of this. And I certainly don't agree with all of
> this being done in common code.
>
> Jan
>

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


Re: [Xen-devel] [PATCH v2 27/41] arm : add helper functions to map memory regions

2015-07-05 Thread Parth Dixit
+shannon

On 8 June 2015 at 19:35, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/2015 21:03, Parth Dixit wrote:
>>
>> creates a helper function for mapping with cached attributes
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>   xen/arch/arm/p2m.c| 26 ++
>>   xen/include/asm-arm/p2m.h | 10 ++
>>   2 files changed, 36 insertions(+)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 903fa3f..fcb8116 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -1140,6 +1140,32 @@ int p2m_populate_ram(struct domain *d,
>>d->arch.p2m.default_access);
>>   }
>>
>> +int map_regions(struct domain *d,
>> + unsigned long start_gfn,
>> + unsigned long nr,
>> + unsigned long mfn)
>
>
> The name doesn't match the behavior. How the user will know that map_regions
> is actually using cached attribute.
>
> Also, I would prefer a function taking the caching attribute in parameter. I
> would be more generic that trying to introduce a new function every time is
> a new attribute is required.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table

2015-07-05 Thread Parth Dixit
+shannon

On 29 May 2015 at 16:13, Jan Beulich  wrote:
 On 29.05.15 at 12:31,  wrote:
>> On Thu, 28 May 2015, Jan Beulich wrote:
>>> >>> On 28.05.15 at 14:12,  wrote:
>>> > Could you please make a concrete suggestion with table names and fields?
>>>
>>> I already pointed you at 6.0's new FADT field "Hypervisor Vendor
>>> Identity".
>>
>> OK, that is a decent alternative.
>>
>> We don't have a suitable hypercall to retrieve the evtchn PPI but we
>> could add one. Overall I still prefer the table approach, but if you
>> really don't want it, I can live with the hypercalls.
>
> I'm clearly not in the position to force any design decision onto the
> ARM side of Xen. But I continue to be of the opinion that custom
> tables should be a last resort approach only, which isn't warranted
> here (anymore).
>
> Jan
>

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


Re: [Xen-devel] [PATCH v2 25/41] arm : acpi add status override table

2015-07-05 Thread Parth Dixit
+shannon

On 18 May 2015 at 01:33, Parth Dixit  wrote:
> Status override table is used to hide devices from DOM0
> that are used by xen
>
> Signed-off-by: Parth Dixit 
> ---
>  xen/include/acpi/actbl2.h | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
> index 25be429..9c8d807 100644
> --- a/xen/include/acpi/actbl2.h
> +++ b/xen/include/acpi/actbl2.h
> @@ -79,6 +79,7 @@
>  #define ACPI_SIG_WDAT   "WDAT" /* Watchdog Action Table */
>  #define ACPI_SIG_WDDT   "WDDT" /* Watchdog Timer Description Table */
>  #define ACPI_SIG_WDRT   "WDRT" /* Watchdog Resource Table */
> +#define ACPI_SIG_STAO   "STAO" /* Status Override Table */
>
>  #ifdef ACPI_UNDEFINED_TABLES
>  /*
> @@ -894,6 +895,19 @@ struct acpi_table_uefi {
>  };
>
>  
> /***
> +  *
> +  * STAO - Status Override Table
> +  *Version 0.3
> +  *
> + 
> **/
> +
> +struct acpi_table_stao {
> +struct acpi_table_header header;   /* Common ACPI table header */
> +u8 uart;/* Indicates presence of SPCR table */
> +u8 devpath[1];/* Full namepath of uart device in ACPI namespace */
> +};
> +
> +/***
>   *
>   * WAET - Windows ACPI Emulated devices Table
>   *Version 1
> --
> 1.9.1
>

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


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

2015-07-05 Thread Parth Dixit
+shannon

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

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


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

2015-07-05 Thread Parth Dixit
+shannon

On 2 June 2015 at 23:10, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> Create a chosen node for DOM0 with
>>  - bootargs
>>  - initrd
>
> I would have merge this patch with #22. It doesn't contain
> controversial/difficult code.
>
>> Signed-off-by: Naresh Bhat 
>> Signed-off-by: Parth Dixit 
>> ---
>>  xen/arch/arm/domain_build.c | 46 
>> +
>>  1 file changed, 46 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index c830702..e688a78 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1219,6 +1219,47 @@ static int handle_node(struct domain *d, struct 
>> kernel_info *kinfo,
>>  return res;
>>  }
>>  #ifdef CONFIG_ACPI
>> +static int make_chosen_node(struct domain *d, const struct kernel_info 
>> *kinfo)
>> +{
>> +int res = 0;
>
> Not necessary to initialize.
>
>> +const char *bootargs = NULL;
>> +const struct bootmodule *mod = kinfo->kernel_bootmodule;
>> +void *fdt = kinfo->fdt;
>> +
>> +DPRINT("Create bootargs chosen node\n");
>
> The name of the node is "chosen" not "bootargs chosen".
>
>> +
>> +if ( mod && mod->cmdline[0] )
>> + bootargs = &mod->cmdline[0];
>> +res = fdt_begin_node(fdt, "chosen");
>> +if ( res )
>> +return res;
>> +
>> +res = fdt_property(fdt, "bootargs", bootargs, (strlen(bootargs)+1));
>
> strlen(bootargs) + 1. And the ( ) around it is not necessary.
>
> Furthermore, you are assuming that bootargs is always present here.
> Although if the module is not present, the variable will be NULL (see
> your check above) and Xen will crash.
>
>> +if ( res )
>> +   return res;
>> +
>> +/*
>> + * If the bootloader provides an initrd, we must create a placeholder
>> + * for the initrd properties. The values will be replaced later.
>> + */
>> +if ( mod && mod->size )
>> +{
>> +u64 a = 0;
>> +res = fdt_property(kinfo->fdt, "linux,initrd-start", &a, sizeof(a));
>> +if ( res )
>> +return res;
>> +
>> +res = fdt_property(kinfo->fdt, "linux,initrd-end", &a, sizeof(a));
>> +if ( res )
>> +return res;
>> +}
>> +
>> +res = fdt_end_node(fdt);
>> +
>> +return res;
>> +}
>> +
>>  /*
>>   * Prepare a minimal DTB for DOM0 which contains
>>   * bootargs, initrd, memory information,
>> @@ -1259,6 +1300,11 @@ static int create_acpi_dtb(struct domain *d, struct 
>> kernel_info *kinfo, struct m
>>  if ( ret )
>>  return ret;
>>
>> +/* Create a chosen node for DOM0 */
>> +ret = make_chosen_node(d, kinfo);
>> +if ( ret )
>> +goto err;
>> +
>>  ret = fdt_end_node(kinfo->fdt);
>>  if ( ret < 0 )
>>  goto err;
>>
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 22/41] arm : acpi create min DT stub for DOM0

2015-07-05 Thread Parth Dixit
+shannon

On 2 June 2015 at 22:57, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> Create a DT for DOM0 for ACPI-case only.
>> DT contains minmal required informations such as
>
> s/minmal/minimal/
>
>> DOM0 bootargs, initrd, efi description table
>> and address of uefi memory table.
>> Add placeholder for tables to be marked as
>> reserved in efi table. This is requird for
>
> s/requird/required/
>
>> DT function's signature.
>
> Well, you can modify later the prototype. It's usually better to define
> where it's used because we can understand why you need this how you will
> use it.
>
> Also, a link the description of the minimal DT in the Linux doc would
> have been nice.
>
>> Signed-off-by: Naresh Bhat 
>> Signed-off-by: Parth Dixit 
>> ---
>>  xen/arch/arm/domain_build.c | 75 
>> -
>>  xen/include/asm-arm/acpi.h  | 10 ++
>>  2 files changed, 84 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 1e545fe..c830702 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -9,6 +9,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -18,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>
> Not necessary, xen/acpi.h already includes asm/acpi.h
>
>>
>>  #include 
>>  #include 
>> @@ -61,6 +63,11 @@ custom_param("dom0_mem", parse_dom0_mem);
>>   */
>>  #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>>
>> +#ifdef CONFIG_ACPI
>> +/* Reserve DOM0 FDT size in ACPI case only */
>> +#define DOM0_FDT_MIN_SIZE 4096
>
> This can be moved within the big #ifdef CONFIG_ACPI below.
> Also please rename the define to show that it's ACPI specific.
>
>> +#endif
>> +
>>  struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
>>  {
>>  if ( opt_dom0_max_vcpus == 0 )
>> @@ -1211,7 +1218,68 @@ static int handle_node(struct domain *d, struct 
>> kernel_info *kinfo,
>>
>>  return res;
>>  }
>
> Newline.
>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Prepare a minimal DTB for DOM0 which contains
>> + * bootargs, initrd, memory information,
>> + * EFI table.
>> + */
>> +static int create_acpi_dtb(struct domain *d, struct kernel_info *kinfo, 
>> struct membank tbl_add[])
>> +{
>> +int new_size;
>> +int ret;
>> +
>> +DPRINT("Prepare a min DTB for DOM0\n");
>> +
>> +/* Allocate min size for DT */
>> +new_size = DOM0_FDT_MIN_SIZE;
>> +kinfo->fdt = xmalloc_bytes(DOM0_FDT_MIN_SIZE);
>
> Why not using new_size here? It would be less error-prone.
>
>> +
>> +if ( kinfo->fdt == NULL )
>> +return -ENOMEM;
>> +
>> +/* Create a new empty DT for DOM0 */
>> +ret = fdt_create(kinfo->fdt, new_size);
>> +if ( ret < 0 )
>> +goto err;
>> +
>> +ret = fdt_finish_reservemap(kinfo->fdt);
>> +if ( ret < 0 )
>> +goto err;
>> +
>> +ret = fdt_begin_node(kinfo->fdt, "/");
>> +if ( ret < 0 )
>> +goto err;
>> +
>> +ret = fdt_property_cell(kinfo->fdt, "#address-cells", 2);
>> +if ( ret )
>> +return ret;
>>
>> +ret = fdt_property_cell(kinfo->fdt, "#size-cells", 1);
>> +if ( ret )
>> +return ret;
>> +
>> +ret = fdt_end_node(kinfo->fdt);
>> +if ( ret < 0 )
>> +goto err;
>> +
>> +ret = fdt_finish(kinfo->fdt);
>> +if ( ret < 0 )
>> +goto err;
>> +
>> +return 0;
>> +
>> +  err:
>> +printk("Device tree generation failed (%d).\n", ret);
>> +xfree(kinfo->fdt);
>> +return -EINVAL;
>> +}
>> +#else
>> +static int create_acpi_dtb(struct domain *d, struct kernel_info *kinfo, 
>> struct membank tbl_add[])
>> +{
>
> Please add a comment and a BUG_ON to make clear this should never be called.
>
>> +return -EINVAL;
>> +}
>> +#endif
>>  static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
>>  {
>>  const void *fdt;
>> @@ -1370,6 +1438,7 @@ int construct_dom0(struct domain *d)
>>  struct kerne

Re: [Xen-devel] [PATCH v2 21/41] arm : acpi Initialize serial port from ACPI SPCR table

2015-07-05 Thread Parth Dixit
+shannon

On 26 May 2015 at 20:34, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/2015 22:03, Parth Dixit wrote:
>>
>> @@ -307,6 +308,54 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
>>   .init = dt_pl011_uart_init,
>>   DT_DEVICE_END
>>
>> +#ifdef CONFIG_ACPI
>> +static int __init acpi_pl011_uart_init(const void *data)
>> +{
>> +struct pl011 *uart;
>> +acpi_status status;
>> +struct acpi_table_spcr *spcr=NULL;
>> +int res;
>> +
>> +status = acpi_get_table(ACPI_SIG_SPCR, 0,
>> +(struct acpi_table_header **)&spcr);
>
>
> Indentation.
>
> And I think this could have been done in the generic UART code. Every UART
> driver will likely need to get the SPCR table.
>
>> +
>> +if ( ACPI_FAILURE(status) )
>> +{
>> +printk("\nFailed to get SPCR table \n");
>
>
> No need of the first newline and the last space.
>
>> +return 1;
>> +}
>> +
>> +uart = &pl011_com;
>> +
>> +if ( spcr->interrupt < 0 )
>
>
> No need of the check, the field interrupt is an u32. Is there any other way
> to find check if the interrupt is valid?
>
>> +{
>> +printk("pl011: Unable to retrieve the IRQ\n");
>> +return -EINVAL;
>> +}
>> +
>> +uart->irq = spcr->interrupt;
>> +/* trigger/polarity information is not available in spcr */
>
>
> If so, how did you find/device that the interrupt is edge? Shouldn't we just
> avoid to configure it?
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 20/41] arm : create generic uart initialization function

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 13:18, Julien Grall  wrote:
>
> On 24/05/2015 08:07, Parth Dixit wrote:
>>
>>
>>
>> On 21 May 2015 at 16:58, Julien Grall > <mailto:julien.gr...@citrix.com>> wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > Rename dt-uart.c to arm-uart.c and create new generic uart init
>> function.
>>  > move dt_uart_init to uart_init.Refactor pl011 driver to dt and
>> common
>> > initialization parts. This will be useful later when acpi specific
>> > uart initialization function is introduced.
>>
>> There is 2 distinct changes in this patch:
>>  - Introduction of the generic UART
>>  - Refactoring of PL011
>>
>> Each changes should be in a separate patch for helping the review.
>>
>> ok, will move into seperate patches.
>
>
> Thank you. It would make sense to gather all the re-factoring patches in the
> beginning of the series. So we could push them without waiting the rest of
> the series.
>
> BTW, it seems that your mail client is using tabulation for quoting which is
> difficult to read after a couple of back and forth. Can you try to configure
> it correctly to use ">"? Maybe it's because of HTML mail?
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 19/41] arm : acpi Add GIC specific ACPI boot support

2015-07-05 Thread Parth Dixit
+shannon

On 21 May 2015 at 17:59, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
>> It needs to parse GIC related subtables, collect CPU interface and 
>> distributor
>> addresses and call driver initialization function (which is hardware
>> abstraction agnostic). In a similar way, FDT initialize GICv2.
>>
>> Modify MADT table to clear GICH and GICV which are not needed
>> in Dom0.
>>
>> NOTE: This commit allow to initialize GICv2 only.
>>
>> Signed-off-by: Tomasz Nowicki 
>> Signed-off-by: Hanjun Guo 
>> Signed-off-by: Naresh Bhat 
>> Signed-off-by: Parth Dixit 
>> ---
>>  xen/arch/arm/gic-v2.c   | 132 +-
>>  xen/arch/arm/gic.c  |  18 +-
>>  xen/drivers/char/arm-uart.c | 136 
>> 
>>  3 files changed, 284 insertions(+), 2 deletions(-)
>>  create mode 100644 xen/drivers/char/arm-uart.c
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 7276951..fcdcd19 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -28,6 +28,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -35,6 +37,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  /*
>>   * LR register definitions are GIC v2 specific.
>> @@ -692,9 +695,122 @@ static int __init dt_gicv2_init(void)
>>  return 0;
>>  }
>>
>> +#ifdef CONFIG_ACPI
>> +static int __init
>> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>> +const unsigned long end)
>> +{
>> +struct acpi_madt_generic_interrupt *processor;
>> +
>> +processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> +if (BAD_MADT_ENTRY(processor, end))
>
> if ( ... )
>
>> +return -EINVAL;
>
> The indentation looks wrong.
>
>> +
>> +/* Read from APIC table and fill up the GIC variables */
>> +
>> +gicv2.cbase = processor->base_address;
>> +gicv2.hbase = processor->gich_base_address;
>> +gicv2.vbase = processor->gicv_base_address;
>
> This is per processor right? The value should be the same on each CPU as
> we don't support non-banked GIC.
>
> You would have to check that each value is the same on every CPU.
>
>> +gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
>> +if( processor->flags & ACPI_MADT_ENABLED )
>
> The check doesn't seem necessary,
>
>> +{
>> +if( processor->flags & ACPI_MADT_VGIC )
>> +set_irq_type(gicv2_info.maintenance_irq, 
>> ACPI_IRQ_TYPE_EDGE_BOTH);
>> +else
>> +set_irq_type(gicv2_info.maintenance_irq, 
>> ACPI_IRQ_TYPE_LEVEL_MASK);
>
> set_irq_type for local IRQ is very expensive. This should be done only one.
>
>> +}
>> +
>> +processor->gich_base_address = 0;
>> +processor->gicv_base_address = 0;
>> +processor->vgic_maintenance_interrupt = 0;
>> +clean_dcache_va_range(processor, sizeof(struct 
>> acpi_madt_generic_interrupt));
>
> Same remark as for the GTDT and MADT table. This doesn't belong to the
> GIC initialization but DOM0 building.
>
> Furthermore, the number of CPU for domain may be different as long as
> the processor->flags.
>
> Overall, I think this table should be recreated for DOM0.
>
>> +return 0;
>> +}
>> +
>> +static int __init
>> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
>> +const unsigned long end)
>> +{
>> +struct acpi_madt_generic_distributor *dist;
>> +
>> +dist = (struct acpi_madt_generic_distributor *)header;
>> +
>> +if (BAD_MADT_ENTRY(dist, end))
>
> if ( ... )
>
>> +return -EINVAL;
>
> The indentation looks wrong
>
>> +
>> +gicv2.dbase = dist->base_address;
>> +
>> +return 0;
>> +}
>> +
>> +static int __init acpi_gicv2_init(void)
>> +{
>> +acpi_status status;
>> +struct acpi_table_header *table;
>> +u8 checksum;
>> +int res;
>
> Given the usage of this variable I w

Re: [Xen-devel] [PATCH v2 18/41] arm: Introduce a generic way to use a device from acpi

2015-07-05 Thread Parth Dixit
+shannon

On 25 May 2015 at 17:08, Parth Dixit  wrote:
> On 25 May 2015 at 15:30, Julien Grall  wrote:
>> Hi Parth,
>>
>> On 25/05/2015 07:58, Parth Dixit wrote:
>>>
>>> On 24 May 2015 at 13:10, Julien Grall  wrote:
>>>>
>>>> On 24/05/2015 08:06, Parth Dixit wrote:
>>>>>
>>>>>
>>>>>   > +struct acpi_device_desc {
>>>>>   > +/* Device name */
>>>>>   > +const char *name;
>>>>>   > +/* Device class */
>>>>>   > +enum device_class class;
>>>>>   > +/* type of device supported by the driver */
>>>>>   > +const int class_type;
>>>>>   > +/* Device initialization */
>>>>>   > +int (*init)(const void *data);
>>>>>   > +};
>>>>>
>>>>>  Given that the number of device will be minimal in Xen, I would
>>>>> prefer
>>>>>  to merge this structure into device_desc by adding the ACPI fields.
>>>>>
>>>>>  It would avoid to duplicate everything for only 2 fields changes.
>>>>>
>>>>>   From the drivers point of view it would look like
>>>>>
>>>>>  DEVICE_START()
>>>>>   .dt_init = ...
>>>>>  #ifdef CONFIG_ACPI
>>>>>   .acpi_init = ...
>>>>>  #endif
>>>>>  DEVICE_END
>>>>>
>>>>>  Or something like
>>>>>
>>>>>  DEVICE_START(...)
>>>>>   DT_INIT(...)
>>>>>   ACPI_INIT(...)
>>>>>  DEVICE_END
>>>>>
>>>>>  And ACPI_INIT will be a no-op when CONFIG_ACPI is not enabled.
>>>>>
>>>>> I think we agreed not to use common structure as it had some dt specific
>>>>> entries and there was scope of confusion.
>>>>
>>>>
>>>>
>>>> I don't remember a such agreement. So far, only compatible and init are
>>>> DT
>>>> specific. The rest (most of the fields) are device agnostic.
>>>
>>> Adding attachment of the previous discussion
>>
>>
>> Thanks. Please a give link to the conversation (such as a mail archive)
>> rather than an attachment. I had to look on the archive to find the context
>> of this conversation...
> ah, sorry about that, i keep forgetting that this conversation is also
> available in public list and i can provide a link to it.
>> Also, that something useful to add in the notes of the patch (after ---).
>>
>> Regards,
>>
>> --
>> Julien Grall

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


Re: [Xen-devel] [PATCH v2 17/41] arm : refactor gic into generic and dt specific parts

2015-07-05 Thread Parth Dixit
+shannon

On 21 May 2015 at 17:52, Julien Grall  wrote:
> On 17/05/15 21:03, Parth Dixit wrote:
>> refactor gic related functions into dt and generic parts
>> this will be helpful when adding acpi support for gic
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>  xen/arch/arm/gic-v2.c | 13 ++---
>>  xen/arch/arm/gic.c|  7 ++-
>>  2 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 80acc62..7276951 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -663,7 +663,7 @@ static hw_irq_controller gicv2_guest_irq_type = {
>>  .set_affinity = gicv2_irq_set_affinity,
>>  };
>>
>> -static int __init gicv2_init(void)
>> +static int __init dt_gicv2_init(void)
>>  {
>>  int res;
>>  const struct dt_device_node *node = gicv2_info.node;
>> @@ -689,6 +689,13 @@ static int __init gicv2_init(void)
>>  panic("GICv2: Cannot find the maintenance IRQ");
>>  gicv2_info.maintenance_irq = res;
>>
>> +return 0;
>> +}
>> +
>> +static int gicv2_init(void)
>> +{
>> + dt_gicv2_init();
>> +
>
> I forgot it on the first review. dt_gicv2_init is returning an error
> code. You should not ignore it.
>
> If it's not useful (because everything paniced), then the function
> should return void.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 16/41] acpi : Introduce acpi_parse_entries

2015-07-05 Thread Parth Dixit
+shannon

On 21 May 2015 at 14:50, Jan Beulich  wrote:
 On 21.05.15 at 11:14,  wrote:
>> On 20 May 2015 at 21:43, Jan Beulich  wrote:
>>
>>> >>> On 17.05.15 at 22:03,  wrote:
>>> > add new function acpi_parse_entries which takes
>>> > acpi table as argument. This will avoid fetching table
>>> > everytime in acpi_table_parse_entries.
>>>
>>> This explanation doesn't make a lot of sense to me - I don't see you
>>> save anything. Am I missing anything? Are you intending to use the
>>> new function separately? Also, please don't break indentation like
>>>
>> yes, i am fetching the table once and parsing it with this function in
>> acpi_gicv2_init function in the patch given below
>> http://lists.xen.org/archives/html/xen-devel/2015-05/msg02208.html
>
> So - just like elsewhere - please correct the patch description then.
>
> Jan
>

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


Re: [Xen-devel] [PATCH v2 15/41] arm : acpi parse GTDT to initialize timer

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 12:30, Parth Dixit  wrote:
>
>
> On 20 May 2015 at 23:33, Julien Grall  wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
>> > Using the information presented by GTDT to initialize the arch
>> > timer (not memory-mapped).
>> >
>> > Clear all el2 fields in GTDT table after initialization
>> > for passing it to Dom0.
>> >
>> > Signed-off-by: Naresh Bhat 
>> > Signed-off-by: Parth Dixit 
>> > ---
>> >  xen/arch/arm/acpi/boot.c   | 50
>> > ++
>> >  xen/arch/arm/time.c| 38 +--
>> >  xen/include/asm-arm/acpi.h |  2 ++
>> >  3 files changed, 79 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
>> > index 7d9758f..a8311ae 100644
>> > --- a/xen/arch/arm/acpi/boot.c
>> > +++ b/xen/arch/arm/acpi/boot.c
>> > @@ -30,6 +30,8 @@
>> >
>> >  #include 
>> >  #include 
>> > +#include 
>> > +#include 
>> >
>> >  /* Processors with enabled flag and sane MPIDR */
>> >  static int enabled_cpus;
>> > @@ -40,6 +42,54 @@ static bool_t __initdata bootcpu_valid;
>> >  /* arch-optional setting to enable display of offline cpus >=
>> > nr_cpu_ids */
>> >  static unsigned int total_cpus = 0;
>> >
>> > +/* Initialize per-processor generic timer */
>> > +void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[])
>>
>> acpi/boot.c begin to be a junk room for all ACPI code. It would have
>> been more logic to have this code in arch/arm/time.c with proper #ifdef.
>>
>> This would have drop the generic_timer_irq which is difficult to
>> understand.
>>
>> > +{
>> > +int type;
>> > +struct acpi_table_gtdt *gtdt=NULL;
>>
>> *gtdt = NULL;
>>
>> > +u8 checksum;
>> > +static const int GTDT_INTRL_TAB[] =
>>
>> all uppercase name are used for define.
>>
>> > +{
>> > +ACPI_IRQ_TYPE_LEVEL_HIGH,
>> > +ACPI_IRQ_TYPE_EDGE_RISING,
>> > +ACPI_IRQ_TYPE_LEVEL_LOW,
>> > +ACPI_IRQ_TYPE_EDGE_FALLING
>> > +};
>>
>> It took me a while to understand how this work.
>>
>> I would prefer an helper which check each field and return/set the
>> correct interrupt type.
>>
>> > +
>> > +acpi_get_table(ACPI_SIG_GTDT, 0, (struct acpi_table_header
>> > **)>dt);
>> > +
>> > +if( gtdt )
>> > +{
>>
>> If gtdt is NULL you will continue without any warning and potentially
>> crash later.
>>
>> Also please do:
>>
>> if ( !gtdt ) {
>>   /* handle error */
>>   return;
>> }
>>
>> /* setup the timer */
>>
>> It's easier to understand and remove one indentation.
>>
>> > +/* Initialize all the generic timer IRQ variable from GTDT
>> > table */
>> > +
>> > +type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags &
>> > ACPI_GTDT_INTR_MASK];
>> > +set_irq_type(gtdt->non_secure_el1_interrupt, type);
>> > +generic_timer_irq[TIMER_PHYS_NONSECURE_PPI] =
>> > +gtdt->non_secure_el1_interrupt;
>> > +
>> > +type = GTDT_INTRL_TAB[gtdt->secure_el1_flags &
>> > ACPI_GTDT_INTR_MASK];
>> > +set_irq_type(gtdt->secure_el1_interrupt, type);
>> > +generic_timer_irq[TIMER_PHYS_SECURE_PPI] =
>> > +gtdt->secure_el1_interrupt;
>> > +
>> > +type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags &
>> > ACPI_GTDT_INTR_MASK];
>> > +set_irq_type(gtdt->non_secure_el2_interrupt, type);
>> > +generic_timer_irq[TIMER_HYP_PPI] =
>> > +gtdt->non_secure_el2_interrupt;
>> > +
>> > +type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags &
>> > ACPI_GTDT_INTR_MASK];
>> > +set_irq_type(gtdt->virtual_timer_interrupt, type);
>> > +generic_timer_irq[TIMER_VIRT_PPI] =
>> > +gtdt->virtual_timer_interrupt;
>> > +
>> > +gtdt->non_secure_el2_interrupt = 0;
>> > +gtdt->non_secure_el2_flags = 0;
>> > +checksum = acpi_tb_che

Re: [Xen-devel] [PATCH v2 13/41] arm/acpi : parse MADT to map logical cpu to MPIDR and get cpu_possible_map

2015-07-05 Thread Parth Dixit
+shannon

On 20 May 2015 at 22:08, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map.
>>
>> Signed-off-by: Hanjun Guo 
>> Signed-off-by: Tomasz Nowicki 
>> Signed-off-by: Naresh Bhat 
>> Signed-off-by: Parth Dixit 
>
> This patch looks very similar to Linux. Unless you say that we have to
> diverge, I would prefer if you important the patch as it is from Linux
> (i.e no coding style changes, stubbing out necessary code) and modify
> only a little bit.
>
> It will be easier to backport fixes from Linux. There are other patches
> where this comment apply.
>
> Also, please check that we are using the latest version of the patch.
>
>> ---
>>  xen/arch/arm/acpi/boot.c | 135 
>> +++
>>  xen/arch/arm/arm64/smpboot.c |   7 ++-
>>  xen/arch/arm/psci.c  |  16 +
>>  xen/arch/arm/smpboot.c   |   7 ++-
>>  xen/include/asm-arm/acpi.h   |   2 +
>>  xen/include/xen/acpi.h   |   5 ++
>>  6 files changed, 170 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
>> index 57eb33c..7d9758f 100644
>> --- a/xen/arch/arm/acpi/boot.c
>> +++ b/xen/arch/arm/acpi/boot.c
>> @@ -29,6 +29,141 @@
>>  #include 
>>
>>  #include 
>> +#include 
>> +
>> +/* Processors with enabled flag and sane MPIDR */
>> +static int enabled_cpus;
>> +
>> +/* Boot CPU is valid or not in MADT */
>> +static bool_t __initdata bootcpu_valid;
>> +
>> +/* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
>> +static unsigned int total_cpus = 0;
>
> Given the usage within this file, the comment is wrong.
>
> Also, please add __init as it's only used during initialization.
>
>> +
>> +/*
>> + * acpi_map_gic_cpu_interface - generates a logical cpu number
>> + * and map to MPIDR represented by GICC structure
>> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
>> + * @enabled: this cpu is enabled or not
>> + *
>> + * Returns the logical cpu number which maps to MPIDR
>> + */
>> +static int __init acpi_map_gic_cpu_interface(u64 mpidr, u8 enabled)
>
> You never use the return value. Please make this function void.
>
>> +{
>> +int i;
>> +
>> +if ( mpidr == MPIDR_INVALID )
>> +{
>> +printk("Skip MADT cpu entry with invalid MPIDR\n");
>> +return -EINVAL;
>> +}
>> +
>> +total_cpus++;
>> +if ( !enabled )
>> +return -EINVAL;
>
> You are skipping the CPU if it's not enabled. How would that fit with
> CPU hotplug?
>
> It looks like that on x86 we allocate disabled CPUs in the possible map
> (see acpi_parse_lapic in arch/x86/acpi/boot.c).
>
>> +
>> +if ( enabled_cpus >=  NR_CPUS )
>> +{
>> +printk("NR_CPUS limit of %d reached, Processor %d/0x%"PRIx64" 
>> ignored.\n",
>> +NR_CPUS, total_cpus, mpidr);
>> +return -EINVAL;
>> +}
>> +
>> +/* Check if GICC structure of boot CPU is available in the MADT */
>> +if ( cpu_logical_map(0) == mpidr )
>> +{
>> +if ( bootcpu_valid )
>> +{
>> +printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in 
>> MADT\n",
>> +mpidr);
>> +return -EINVAL;
>> +}
>> +
>> +bootcpu_valid = TRUE;
>> +}
>> +
>> +/*
>> + * Duplicate MPIDRs are a recipe for disaster. Scan
>> + * all initialized entries and check for
>> + * duplicates. If any is found just ignore the CPU.
>> + */
>> +for ( i = 1; i < enabled_cpus; i++ )
>> +{
>> +if ( cpu_logical_map(i) == mpidr )
>> +{
>> +printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in 
>> MADT\n",
>> +mpidr);
>> +return -EINVAL;
>> +}
>> +}
>> +
>> +if ( !acpi_psci_present() )
>> +return -EOPNOTSUPP;
>> +
>> +/* CPU 0 was already initialized */
>> +if ( enabled_cpus )
>> +{
>>

Re: [Xen-devel] [PATCH v2 14/41] arm : acpi add helper function for setting interrupt type

2015-07-05 Thread Parth Dixit
+shannon

On 20 May 2015 at 22:51, Julien Grall  wrote:
> Hi,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> set edge/level type information for an interrupt
>>
>> Signed-off-by: Parth Dixit 
>> ---
>>  xen/arch/arm/irq.c | 17 +
>>  xen/include/asm-arm/acpi.h | 26 ++
>>  xen/include/asm-arm/irq.h  |  2 ++
>>  3 files changed, 45 insertions(+)
>>
>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>> index 376c9f2..1713935 100644
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -679,6 +679,23 @@ int platform_get_irq(const struct dt_device_node 
>> *device, int index)
>>  return irq;
>>  }
>>
>> +int set_irq_type(int irq,int type)
>
>
> int set_irq_type(unsigned int irq, unsigned int type)
>
>> +{
>> +int res;
>> +
>> +/* Setup the IRQ type */
>> +if ( irq < NR_LOCAL_IRQS )
>> +res = irq_local_set_type(irq, type);
>> +else
>> +res = irq_set_spi_type(irq, type);
>> +
>> +if ( res )
>> +return -1;
>
> It would be better to return res which contain a more meaningful error
> than -1.
>
>> +
>> +return 0;
>> +
>> +}
>> +
>
> At the same time, please call this function from platform_get_irq as the
> code is the same.
>
> Furthermore, please move the function code with the other irq_set_*
> function and rename it to irq_set_type in order to keep the same naming
> convention.
>
>>  /*
>>   * Local variables:
>>   * mode: C
>> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
>> index 0845f14..1767143 100644
>> --- a/xen/include/asm-arm/acpi.h
>> +++ b/xen/include/asm-arm/acpi.h
>> @@ -50,4 +50,30 @@ static inline void disable_acpi(void)
>>
>>  #define ACPI_GTDT_INTR_MASK ( ACPI_GTDT_INTERRUPT_MODE | 
>> ACPI_GTDT_INTERRUPT_POLARITY )
>>
>> +/**
>> + * IRQ line type.
>> + *
>> + * ACPI_IRQ_TYPE_NONE- default, unspecified type
>> + * ACPI_IRQ_TYPE_EDGE_RISING - rising edge triggered
>> + * ACPI_IRQ_TYPE_EDGE_FALLING- falling edge triggered
>> + * ACPI_IRQ_TYPE_EDGE_BOTH   - rising and falling edge triggered
>> + * ACPI_IRQ_TYPE_LEVEL_HIGH  - high level triggered
>> + * ACPI_IRQ_TYPE_LEVEL_LOW   - low level triggered
>> + * ACPI_IRQ_TYPE_LEVEL_MASK  - Mask to filter out the level bits
>> + * ACPI_IRQ_TYPE_SENSE_MASK  - Mask for all the above bits
>> + * ACPI_IRQ_TYPE_INVALID - Use to initialize the type
>> + */
>> +#define ACPI_IRQ_TYPE_NONE   0x
>> +#define ACPI_IRQ_TYPE_EDGE_RISING0x0001
>> +#define ACPI_IRQ_TYPE_EDGE_FALLING   0x0002
>> +#define ACPI_IRQ_TYPE_EDGE_BOTH   \
>> +(ACPI_IRQ_TYPE_EDGE_FALLING | ACPI_IRQ_TYPE_EDGE_RISING)
>> +#define ACPI_IRQ_TYPE_LEVEL_HIGH 0x0004
>> +#define ACPI_IRQ_TYPE_LEVEL_LOW  0x0008
>> +#define ACPI_IRQ_TYPE_LEVEL_MASK  \
>> +(ACPI_IRQ_TYPE_LEVEL_LOW | ACPI_IRQ_TYPE_LEVEL_HIGH)
>> +#define ACPI_IRQ_TYPE_SENSE_MASK 0x000f
>> +
>> +#define ACPI_IRQ_TYPE_INVALID0x0010
>> +
>
> While having a function to set the type is a good idea.
> Using a separate set a define and mixing them together is wrong.
>
> In Xen we only care about edge vs level.
>
> Although, if you really want to keep all these types. It should be
> firmware agnostic.
>
>
>>  #endif /*_ASM_ARM_ACPI_H*/
>> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
>> index 34b492b..ddad0a9 100644
>> --- a/xen/include/asm-arm/irq.h
>> +++ b/xen/include/asm-arm/irq.h
>> @@ -51,6 +51,8 @@ void arch_move_irqs(struct vcpu *v);
>>  /* Set IRQ type for an SPI */
>>  int irq_set_spi_type(unsigned int spi, unsigned int type);
>>
>> +int set_irq_type(int irq,int type);
>
> int set_irq_type(unsigned int irq, unsigned int type);
>
>> +
>>  int platform_get_irq(const struct dt_device_node *device, int index);
>>
>>  void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
>>
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 12/41] arm : move dt specific code in smp to seperate functions

2015-07-05 Thread Parth Dixit
+shannon

On 20 May 2015 at 21:13, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> +void __init smp_init_cpus(void)
>> +{
>> +int rc;
>
> Missing blank line here.
>
>> +/* initialize PSCI and set a global variable */
>> +psci_init();
>> +
>> +if ( (rc = arch_smp_init()) < 0 )
>> +{
>> +printk(XENLOG_WARNING "SMP init failed (%d)\n"
>> +   "Using only 1 CPU\n", rc);
>> +return;
>> +}
>> +
>> +dt_smp_init_cpus();
>> +}
>> +
>>  int __init
>>  smp_get_max_cpus (void)
>>  {
>>
>
> Regards,
>
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 11/41] arm/acpi : add GTDT support updated by ACPI 5.1

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 11:36, Parth Dixit  wrote:
>
>
> On 18 May 2015 at 20:41, Julien Grall  wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > With ACPI 5.0, we got per-processor timer support in GTDT,
>> > and ACPI 5.1 introduced the support for platform (memory-mapped)
>> > timers: GT Block and SBSA watchdog timer, add the code needed
>> > for the spec change.
>> >
>> > Signed-off-by: Hanjun Guo 
>> > Signed-off-by: Naresh Bhat 
>> > Signed-off-by: Parth Dixit 
>> > ---
>> >  xen/include/acpi/actbl3.h  | 92
>> > +++---
>> >  xen/include/asm-arm/acpi.h |  2 +
>> >  2 files changed, 80 insertions(+), 14 deletions(-)
>> >
>> > diff --git a/xen/include/acpi/actbl3.h b/xen/include/acpi/actbl3.h
>> > index 8c61b5f..7664f9d 100644
>> > --- a/xen/include/acpi/actbl3.h
>> > +++ b/xen/include/acpi/actbl3.h
>> > @@ -241,33 +241,97 @@ struct acpi_s3pt_suspend {
>> >
>> >
>> > /***
>> >   *
>> > - * GTDT - Generic Timer Description Table (ACPI 5.0)
>> > + * GTDT - Generic Timer Description Table (ACPI 5.1)
>> >   *Version 1
>> >   *
>> >
>> > **/
>> >
>> >  struct acpi_table_gtdt {
>> >   struct acpi_table_header header;/* Common ACPI table
>> > header */
>> > - u64 address;
>> > - u32 flags;
>> > - u32 secure_pl1_interrupt;
>> > - u32 secure_pl1_flags;
>> > - u32 non_secure_pl1_interrupt;
>> > - u32 non_secure_pl1_flags;
>> > + u64 cnt_control_base_address;
>>
>> This patch is out-of-sync compare to the Linux one (naming different,
>> comment...). Can you update it?
>>
> sure, i'll take care in next patchset.
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>

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


Re: [Xen-devel] [PATCH v2 10/41] arm/acpi : Print GIC information when MADT is parsed

2015-07-05 Thread Parth Dixit
+shannon


On 24 May 2015 at 11:39, Parth Dixit  wrote:
>
>
> On 18 May 2015 at 20:36, Julien Grall  wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > From: Naresh Bhat 
>> >
>> > When MADT is parsed, print GIC information to make the boot
>> > log look pretty.
>> >
>> > Signed-off-by: Hanjun Guo 
>> > Signed-off-by: Tomasz Nowicki 
>> > Signed-off-by: Naresh Bhat 
>> > ---
>> >  xen/drivers/acpi/tables.c | 39 +++
>> >  1 file changed, 39 insertions(+)
>> >
>> > diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
>> > index 1beca79..684d8c9 100644
>> > --- a/xen/drivers/acpi/tables.c
>> > +++ b/xen/drivers/acpi/tables.c
>> > @@ -190,6 +190,45 @@ void __init acpi_table_print_madt_entry(struct
>> > acpi_subtable_header *header)
>> >   }
>> >   break;
>> >
>> > +case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
>> > +{
>> > +struct acpi_madt_generic_interrupt *p =
>> > +(struct acpi_madt_generic_interrupt *)header;
>> > +printk(KERN_INFO PREFIX
>> > +"GIC (acpi_id[0x%04x] gic_id[0x%04x] %s)\n",
>> > +p->uid, p->gic_id,
>> > +(p->flags & ACPI_MADT_ENABLED) ? "enabled" :
>> > "disabled");
>>
>> Printk indentation:
>>
>> printk(KERN_INFO PREFIX
>>"GIC ...
>>...);
>>
>> Also, it seems that the indentation doesn't match the rest of the switch
>> case.
>>
>> > +}
>> > +break;
>> > +
>> > +case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
>> > +{
>> > +struct acpi_madt_generic_distributor *p =
>> > +(struct acpi_madt_generic_distributor *)header;
>> > +printk(KERN_INFO PREFIX
>> > +"GIC Distributor (id[0x%04x] address[0x%08llx]
>> > gsi_base[%d])\n",
>> > +p->gic_id, (long long unsigned int)p->base_address,
>> > p->global_irq_base);
>>
>> Ditto
>>
>> > +}
>> > +break;
>> > +
>> > +case ACPI_MADT_TYPE_GIC_MSI_FRAME:
>> > +{
>> > +struct acpi_madt_gic_msi_frame *p =
>> > +(struct acpi_madt_gic_msi_frame *)header;
>> > +printk("GIC MSI Frame (address[0x%08llx]
>> > msi_fame_id[%d])\n",
>> > +(long long unsigned int)p->base_address,
>> > p->gic_msi_frame_id);
>>
>> Ditto & missing KERN_INFO PREFIX
>>
>> > +}
>> > +break;
>> > +
>> > +case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
>> > +{
>> > +struct acpi_madt_gic_redistributor *p =
>> > +(struct acpi_madt_gic_redistributor *)header;
>> > +printk("GIC Redistributor (address[0x%08llx]
>> > region_size[0x%x])\n",
>> > +(long long unsigned int)p->base_address,
>> > p->region_size);
>>
>> Ditto & missing KERN_INFO PREFIX
>
>  will take care in next patchset.
>>
>>
>> > +}
>> > +break;
>> > +
>> >   default:
>> >   printk(KERN_WARNING PREFIX
>> >  "Found unsupported MADT entry (type = %#x)\n",
>> >
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>

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


Re: [Xen-devel] [PATCH v2 09/41] arm/acpi : Add Generic Interrupt and Distributor struct

2015-07-05 Thread Parth Dixit
+shannon

On 18 May 2015 at 01:33, Parth Dixit  wrote:
> Add Generic Interrupt and Distributor (ACPI 5.0) structure.
> Add new features for MADT introduced by ACPI 5.1.
> Comment on the GIC ID field of the GIC structure which is replaced
> by CPU Interface Number.
> Add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
> Add new structures for GIC MSI frame and GICR.
> Add flag definition for GICC flags.
>
> Signed-off-by: Tomasz Nowicki 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: Naresh Bhat 
> Signed-off-by: Parth Dixit 
> ---
>  xen/include/acpi/actbl1.h | 62 
> +--
>  1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index 9311e3a..2d72d8a 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -639,7 +639,11 @@ enum acpi_madt_type {
> ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
> ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
> ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
> -   ACPI_MADT_TYPE_RESERVED = 11/* 11 and greater are reserved */
> +   ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
> +   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> +   ACPI_MADT_TYPE_GIC_MSI_FRAME = 13,
> +   ACPI_MADT_TYPE_GIC_REDISTRIBUTOR = 14,
> +   ACPI_MADT_TYPE_RESERVED = 15/* 15 and greater are reserved */
>  };
>
>  /*
> @@ -760,14 +764,68 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3];
>  };
>
> +/* 11: Generic Interrupt (ACPI 5.1) */
> +
> +struct acpi_madt_generic_interrupt {
> +struct acpi_subtable_header header;
> +u16 reserved;   /* reserved - must be zero */
> +u32 gic_id; /* it was renamed to cpu interface number in ACPI 5.1 */
> +u32 uid;
> +u32 flags;
> +u32 parking_version;
> +u32 performance_interrupt;
> +u64 parked_address;
> +u64 base_address;
> +u64 gicv_base_address;
> +u64 gich_base_address;
> +u32 vgic_maintenance_interrupt;
> +u64 redist_base_address;
> +u64 mpidr;
> +
> +};
> +
> +/* 12: Generic Distributor (ACPI 5.0) */
> +
> +struct acpi_madt_generic_distributor {
> +struct acpi_subtable_header header;
> +u16 reserved;   /* reserved - must be zero */
> +u32 gic_id;
> +u64 base_address;
> +u32 global_irq_base;
> +u32 reserved2;  /* reserved - must be zero */
> +};
> +
> +/* 13: GIC MSI Frame (ACPI 5.1) */
> +
> +struct acpi_madt_gic_msi_frame {
> +struct acpi_subtable_header header;
> +u16 reserved;   /* reserved - must be zero */
> +u32 gic_msi_frame_id;
> +u64 base_address;
> +};
> +
> +/* 14: GIC Redistributor (ACPI 5.1) */
> +
> +struct acpi_madt_gic_redistributor {
> +struct acpi_subtable_header header;
> +u16 reserved;   /* reserved - must be zero */
> +u64 base_address;
> +u32 region_size;
> +};
> +
>  /*
>   * Common flags fields for MADT subtables
>   */
>
> -/* MADT Local APIC flags (lapic_flags) */
> +/* MADT Local APIC flags (lapic_flags) and GICC flags */
>
>  #define ACPI_MADT_ENABLED   (1)/* 00: Processor is usable if 
> set */
>
> +/* MADT GICC flags only */
> +
> +#define ACPI_MADT_PERF_INT_MODE (1<<1) /* 01: Performance Interrupt 
> Mode */
> +#define ACPI_MADT_VGIC  (1<<2) /* 02: VGIC Maintenance 
> interrupt mode */
> +
>  /* MADT MPS INTI flags (inti_flags) */
>
>  #define ACPI_MADT_POLARITY_MASK (3)/* 00-01: Polarity of APIC 
> I/O input signals */
> --
> 1.9.1
>

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


Re: [Xen-devel] [PATCH v2 08/41] arm/acpi : Parse FADT table and get PSCI flags

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 11:35, Parth Dixit  wrote:
>
>
> On 18 May 2015 at 20:28, Julien Grall  wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
>> > the former signals to the OS that the hardware is PSCI compliant.
>> > The latter selects the appropriate conduit for PSCI calls by
>> > toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
>> > (SMC).
>> >
>> > FADT table contains such information, parse FADT to get the flags
>> > for furture usage. At the same time, only ACPI 5.1 or higher verison
>> > supports PSCI, and FADT Major.Minor version was introduced in ACPI
>> > 5.1, so we will check the version and only parse FADT table with
>> > version >= 5.1.
>> >
>> > If firmware provides ACPI tables with ACPI version less than 5.1,
>> > OS will be messed up with those information, so disable ACPI if we
>> > get an FADT table with version less that 5.1.
>> >
>> > Modify FADT table before passing it to Dom0.
>> > Set PSCI_COMPLIANT and PSCI_USE_HVC.
>> >
>> > Signed-off-by: Hanjun Guo 
>> > Signed-off-by: Naresh Bhat 
>> > Signed-off-by: Parth Dixit 
>> > ---
>> >  xen/arch/arm/acpi/boot.c   | 38 ++
>> >  xen/arch/arm/acpi/lib.c| 11 +++
>> >  xen/include/asm-arm/acpi.h | 11 +++
>> >  3 files changed, 60 insertions(+)
>> >
>> > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
>> > index 8dc69d5..57eb33c 100644
>> > --- a/xen/arch/arm/acpi/boot.c
>> > +++ b/xen/arch/arm/acpi/boot.c
>> > @@ -24,9 +24,40 @@
>> >
>> >  #include 
>> >  #include 
>> > +#include 
>> > +#include 
>> > +#include 
>> >
>> >  #include 
>> >
>> > +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> > +{
>> > +struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> > +u8 checksum;
>> > +
>> > +/*
>> > + * Revision in table header is the FADT Major revision, and there
>> > + * is a minor revision of FADT which was introduced by ACPI 5.1,
>> > + * we only deal with ACPI 5.1 or newer revision to get GIC and SMP
>> > + * boot protocol configuration data, or we will disable ACPI.
>> > + */
>> > +if ( table->revision > 5 ||
>> > +( table->revision == 5 && fadt->minor_revision >= 1 ) )
>>
>> The indentation looks wrong here.
>>
>> > +{
>> > +fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT |
>> > ACPI_FADT_PSCI_USE_HVC );
>> > +checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt),
>> > fadt->header.length);
>> > +fadt->header.checksum -= checksum;
>> > +clean_dcache_va_range(fadt, sizeof(struct acpi_table_fadt));
>>
>> Most of this patch is dealing with setting up correctly DOM0 FADT
>> although the title doesn't mention it and there is only 2 lines in the
>> commit message. This would also need comment in the need explaining what
>> this code does.
>>
>> Furthermore, I don't think this code should live here. The function is
>> called by acpi_boot_table_init which should initialize ACPI and not
>> trying to modify the ACPI table.
>>
> i'll split it into two patches with modifying of fadt going into seperate
> patch.
>>
>> We should have a specific dom0 acpi function to modify/add ACPI table
>> when it's necessary.
>>
>> > +return 0;
>> > +}
>> > +
>> > +printk("Unsupported FADT revision %d.%d, should be 5.1+, will
>> > disable ACPI\n",
>> > +table->revision, fadt->minor_revision);
>> > +disable_acpi();
>> > +
>> > +return -EINVAL;
>> > +}
>> > +
>> >  /*
>> >   * acpi_boot_table_init() called from setup_arch(), always.
>> >   *  1. find RSDP and get its address, and then find XSDT
>> > @@ -51,6 +82,13 @@ int __init acpi_boot_table_init(void)
>> >  return error;
>> >  }
>> >
>> > +if ( acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt) )
>> > +{
>> > +/* disable ACPI if no FADT is found */
>> > +disable_acpi();
>> > +printk(

Re: [Xen-devel] [PATCH v2 07/41] arm/acpi : Introduce ARM Boot Architecture Flags in FADT

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 11:33, Parth Dixit  wrote:
>
>
> On 18 May 2015 at 19:59, Julien Grall  wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > The Power State Coordination Interface (PSCI) defines an API that
>> > can be used to coordinate power control amongst the various supervisory
>> > systems concurrently running on a device. ACPI support for this
>> > technology would require the addition of two flags: PSCI_COMPLIANT and
>> > PSCI_USE_HVC. When set, the former signals to the OS that the hardware
>> > is PSCI compliant. The latter selects the appropriate conduit for PSCI
>> > calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
>> > Calls (SMC).
>> >
>> > An ARM Boot Architecture Flags structure to support new ARM hardware
>> > was introduced in FADT in ACPI 5.1, add the code accordingly to
>> > implement that in ACPICA core.
>> >
>> > Since ACPI 5.1 doesn't support self defined PSCI function IDs,
>> > which means that only PSCI 0.2+ is supported in ACPI.
>> >
>> > Signed-off-by: Hanjun Guo 
>> > Signed-off-by: Naresh Bhat 
>> > ---
>> >  xen/include/acpi/actbl.h | 10 --
>> >  1 file changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
>> > index 856945d..96fd1d8 100644
>> > --- a/xen/include/acpi/actbl.h
>> > +++ b/xen/include/acpi/actbl.h
>> > @@ -244,7 +244,8 @@ struct acpi_table_fadt {
>> >   u32 flags;  /* Miscellaneous flag bits (see below for
>> > individual flags) */
>> >   struct acpi_generic_address reset_register; /* 64-bit address
>> > of the Reset register */
>> >   u8 reset_value; /* Value to write to the reset_register
>> > port to reset the system */
>> > - u8 reserved4[3];/* Reserved, must be zero */
>> > +u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below
>> > for individual flags) */
>> > +u8 minor_revision;   /* Minor version of this FADT structure */
>>
>> Wrong indentation. The file is using hard tab.
>>
>> >   u64 Xfacs;  /* 64-bit physical address of FACS */
>> >   u64 Xdsdt;  /* 64-bit physical address of DSDT */
>> >   struct acpi_generic_address xpm1a_event_block;  /* 64-bit Extended
>> > Power Mgt 1a Event Reg Blk address */
>> > @@ -270,6 +271,11 @@ struct acpi_table_fadt {
>> >
>> >  #define FADT2_REVISION_ID   3
>> >
>> > +/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
>> > +
>> > +#define ACPI_FADT_PSCI_COMPLIANT(1)/* 00: PSCI 0.2+ is
>> > implemented */
>> > +#define ACPI_FADT_PSCI_USE_HVC  (1<<1) /* 01: HVC must be used
>> > instead of SMC as the PSCI conduit */
>> > +
>> >  /* Masks for FADT flags */
>> >
>> >  #define ACPI_FADT_WBINVD(1)  /* 00: [V1] The wbinvd
>> > instruction works properly */
>> > @@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
>> >   * FADT V5  size: 0x10C
>> >   */
>> >  #define ACPI_FADT_V1_SIZE   (u32) (ACPI_FADT_OFFSET (flags) + 4)
>> > -#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (reserved4[0])
>> > + 3)
>> > +#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET
>> > (arm_boot_flags) + 3)
>>
>> Linux is using ACPI_FADT_OFFSET(minor_revision) + 1. Can you use the
>> same here?
>>
>> Also, I've notice that the patch (see 9eb1105) is slightly different.
>> Mostly documenting the ACPI version for the fields.
>>
>> Can you update the patch based on Linux code to use the latest version
>> (i.e the version upstreamed)?
>>
> sure, i'll update it to be in sync with linux.
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>

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


Re: [Xen-devel] [PATCH v2 06/41] arm/acpi : Add basic ACPI initialization

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 11:32, Parth Dixit  wrote:
>
>
> On 18 May 2015 at 19:41, Julien Grall  wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > acpi_boot_table_init() will be called in start_xen
>> > to get the RSDP and all the table pointers. with this patch,
>> > we can get ACPI boot-time tables from firmware on ARM64.
>> >
>> > Signed-off-by: Naresh Bhat 
>> > Signed-off-by: Parth Dixit 
>> > ---
>> >  xen/arch/arm/acpi/Makefile |  1 +
>> >  xen/arch/arm/acpi/boot.c   | 56
>> > ++
>> >  xen/arch/arm/setup.c   | 13 +--
>> >  3 files changed, 68 insertions(+), 2 deletions(-)
>> >  create mode 100644 xen/arch/arm/acpi/boot.c
>> >
>> > diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
>> > index b5be22d..196c40a 100644
>> > --- a/xen/arch/arm/acpi/Makefile
>> > +++ b/xen/arch/arm/acpi/Makefile
>> > @@ -1 +1,2 @@
>> >  obj-y += lib.o
>> > +obj-y += boot.o
>> > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
>> > new file mode 100644
>> > index 000..8dc69d5
>> > --- /dev/null
>> > +++ b/xen/arch/arm/acpi/boot.c
>> > @@ -0,0 +1,56 @@
>> > +/*
>> > + *  ARM64 Specific Low-Level ACPI Boot Support
>>
>> This code is not ARM64 specific:
>>
>> s/ARM64/ARM/
>>
>> > + *
>> > + *  Copyright (C) 2014, Naresh Bhat 
>>
>> The code within this file is a copy of arch/x86/acpi/boot.c.
>>
>> Please retain the copyright and add yours if necessary.
>>
>> > + *
>> > + *
>> > ~~
>> > + *
>> > + *  This program is free software; you can redistribute it and/or
>> > modify
>> > + *  it under the terms of the GNU General Public License as published
>> > by
>> > + *  the Free Software Foundation; either version 2 of the License, or
>> > + *  (at your option) any later version.
>> > + *
>> > + *  This program is distributed in the hope that it will be useful,
>> > + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > + *  GNU General Public License for more details.
>> > + *
>> > + *  You should have received a copy of the GNU General Public License
>> > + *  along with this program; if not, write to the Free Software
>> > + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
>> > 02111-1307  USA
>> > + *
>> > + *
>> > ~~
>> > + */
>> > +
>> > +#include 
>> > +#include 
>> > +
>> > +#include 
>> > +
>> > +/*
>> > + * acpi_boot_table_init() called from setup_arch(), always.
>> > + *  1. find RSDP and get its address, and then find XSDT
>> > + *  2. extract all tables and checksums them all
>> > + *
>> > + * We can parse ACPI boot-time tables such as FADT, MADT after
>> > + * this function is called.
>>
>> It's worth to expand the commit message as done in the x86 version
>> to explain the return value.
>>
>> > + */
>> > +int __init acpi_boot_table_init(void)
>> > +{
>> > +int error;
>> > +
>> > +/* If acpi_disabled, bail out */
>> > +if ( acpi_disabled )
>> > +return 1;
>> > +
>> > +/* Initialize the ACPI boot-time table parser. */
>> > +error = acpi_table_init();
>>
>> I didn't find a better place for this comment. Though it's related to
>> the ACPI initialization...
>>
>> You need to change_acpi_os_get_root_pointer, the current behavior is to
>> fallback on the legacy method (i.e scanning the first MB of memory) when
>> efi_enabled 0.
>>
> sure, will take care in next patchset.
>>
>> > +if ( error )
>> > +{
>> > +disable_acpi();
>> > +return error;
>> > +}
>> > +
>> > +return 0;
>> > +}
>> > +
>> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> > index 06f8e54..5711077 100644
>> > --- a/xen/arch/arm/setup.c
>> > +++ b/xen/arch/arm/setup.c
>> > @@ -36,6 +36,7 @@
>> >  #include 
&

Re: [Xen-devel] [PATCH v2 05/41] acpi : add helper function for mapping memory

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 13:01, Julien Grall  wrote:
> Hi Parth,
>
> On 24/05/2015 07:40, Parth Dixit wrote:
>>
>>     On 17/05/15 21:03, Parth Dixit wrote:
>>  > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>>  > index 935999e..096e9ef 100644
>>  > --- a/xen/arch/arm/Makefile
>>  > +++ b/xen/arch/arm/Makefile
>>  > @@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
>>  >  subdir-$(arm64) += arm64
>>  >  subdir-y += platforms
>>  >  subdir-$(arm64) += efi
>>  > +subdir-$(HAS_ACPI) += acpi
>>  >
>>  >  obj-$(EARLY_PRINTK) += early_printk.o
>>  >  obj-y += cpu.o
>>  > diff --git a/xen/arch/arm/acpi/Makefile
>> b/xen/arch/arm/acpi/Makefile
>>  > new file mode 100644
>>  > index 000..b5be22d
>>  > --- /dev/null
>>  > +++ b/xen/arch/arm/acpi/Makefile
>>  > @@ -0,0 +1 @@
>>  > +obj-y += lib.o
>>  > diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
>>  > new file mode 100644
>>  > index 000..650beed
>>  > --- /dev/null
>>  > +++ b/xen/arch/arm/acpi/lib.c
>>  > @@ -0,0 +1,8 @@
>>  > +#include 
>>  > +#include 
>>  > +
>>  > +void __iomem *
>>  > +acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>>  > +{
>>  > +return __va(phys);
>>  > +}
>>
>> I would have prefer two distinct patch: one for the refactoring of
>> acpi_os_map_memory and the other for implementing the ARM part
>> explaining why only using __va.
>>
>> __va should only be used when the memory is direct-mapped to Xen (i.e
>> accessible directly). On ARM64, this only the case for the RAM. Can
>> you
>> confirm that ACPI will always reside to the RAM?
>>
>> I already asked the same question on the previous version but got no
>> answer from you...
>>
>> I did not found any document which says it will always reside in RAM or
>> otherwise..
>
>
> If so, you have use vmap or ioremap_cache as suggested by Jan.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 04/41] arm/acpi : add arm specific acpi header file

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 11:29, Parth Dixit  wrote:
>
>
> On 18 May 2015 at 18:42, Julien Grall  wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > +#ifndef _ASM_ARM64_ACPI_H
>> > +#define _ASM_ARM64_ACPI_H
>>
>> s/_ASM_ARM64_ACPI_H/_ASM_ARM_ACPI_H/
>>
>> > +
>> > +#include 
>> > +
>> > +#define COMPILER_DEPENDENT_INT64   long long
>> > +#define COMPILER_DEPENDENT_UINT64  unsigned long long
>> > +
>> > +extern bool_t acpi_disabled;
>> > +/* Basic configuration for ACPI */
>> > +static inline void disable_acpi(void)
>> > +{
>> > +acpi_disabled = 1;
>> > +}
>>
>> It makes a little sense to add the prototype of acpi_disabled without
>> effectively declaring it.
>>
>> Also, the code is very similar to the x86. It would make sense to
>> factorize it (disable_acpi, acpi parameters...) in a common place.
>>
> sure, i will take care in next patch set.
>>
>> > +#endif /*_ASM_ARM_ACPI_H*/
>> >
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>

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


Re: [Xen-devel] [PATCH v2 02/41] arm/acpi: Build pmstat for x86 only

2015-07-05 Thread Parth Dixit
+shannon

On 24 May 2015 at 11:40, Parth Dixit  wrote:
>
>
> On 20 May 2015 at 20:42, Jan Beulich  wrote:
>>
>> >>> On 17.05.15 at 22:03,  wrote:
>> > Pmstat is currently not supported for arm in xen.
>> > Configure and build pmstat for x86 architecture only.
>>
>> Same here as for patch 1. If the architecture can be expected to
>> eventually support a feature, I'd generally prefer the architecture
>> to get necessary stubs added over fiddling with common code.
>>
> ok, will add stubs in next patchset.
>>
>> > --- a/xen/common/sysctl.c
>> > +++ b/xen/common/sysctl.c
>> > @@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
>> > u_sysctl)
>> >  op->u.availheap.avail_bytes <<= PAGE_SHIFT;
>> >  break;
>> >
>> > +#ifdef CONFIG_X86
>> >  #ifdef HAS_ACPI
>> >  case XEN_SYSCTL_get_pmstat:
>> >  ret = do_get_pm_info(&op->u.get_pmstat);
>>
>> Please fold the two #if-s into one, or even replace the HAS_ACPI
>> one if this really needs to be done.
>>
>> Jan
>>
>

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


Re: [Xen-devel] [PATCH v2 03/41] arm/acpi : emulate io ports for arm

2015-07-05 Thread Parth Dixit
+shannon

On 18 May 2015 at 18:33, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> add macros to emulate x86 style ports for arm.
>> This avoids modification in common code for acpi.
>
> This patch looks wrong to me. On ARM ioport access is done using the PCI
> address space.
>
> If it's not easy to have a correct implementation, I still prefer
> modification in common ACPI code.
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 01/41] arm/acpi: Build numa for x86 only

2015-07-05 Thread Parth Dixit
+shannon

On 20 May 2015 at 22:01, Jan Beulich  wrote:
 On 20.05.15 at 17:49,  wrote:
>> What about defining a new define HAVE_NUMA?
>
> That might be an acceptable compromise.
>
> Jan
>

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


Re: [Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions

2015-06-14 Thread Parth Dixit
On 8 June 2015 at 22:20, Julien Grall  wrote:
> Hi Parth,
>
> On 17/05/2015 21:03, Parth Dixit wrote:
>>
>> In ACPI mmio regions are described in DSDT which requires
>> AML interpreter. Defer the mapping of mmio until DSDT is parsed in
>> DOM0 and map mmio's dynamically at the time of request.
>
>
> I'm against a such solution. Even though it's DOM0 we should avoid to allow
> him to map anything (RAM,...) on data abort.
I think we agreed to this solution
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02059.html

> During DOM0 creation, we should map anything that is not RAM and not used by
> Xen to DOM0. IIRC, this is how it works on x86.
>
> I'm nearly sure we talked about it during the Linaro Connect. Please give
> details if you thing it won't work...
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [edk2] MMIO regions in GetMemoryMap ()0 (fwd)

2015-06-13 Thread Parth Dixit
+xen dev list

On 24 February 2015 at 20:25, Stefano Stabellini
 wrote:
> On Fri, 13 Feb 2015, Julien Grall wrote:
>> On 13/02/2015 11:44, Ard Biesheuvel wrote:
>> > On 13 February 2015 at 11:12, Julien Grall  wrote:
>> > >
>> > >
>> > > On 13/02/2015 10:29, Stefano Stabellini wrote:
>> > > >
>> > > > Hello all,
>> > > >
>> > > > Unfortunately Dong Wei was wrong about the possibility of using the 
>> > > > UEFI
>> > > > System Memory Map to retrieve the list of MMIO regions on the system, 
>> > > > as
>> > > > it could be lacking some.
>> > > >
>> > > > A possible alternative, suggested by Ian, would be to map MMIO regions
>> > > > into Dom0 on demand whenever Dom0 traps into Xen trying to read/write 
>> > > > to
>> > > > a page that is not normal memory. The page would be identified as
>> > > > belonging to an unadvertised MMIO region and mapped in the p2m at that
>> > > > point.
>> > >
>> > >
>> > > There is one issue with this solution. How do you know if you have to map
>> > > the MMIO region cache or uncached?
>> > >
>> >
>> > The UEFI spec mandates that the memory map describes all memory in the
>> > system, so if dom0 accesses any ranges outside of that, it makes sense
>> > to just use device mappings for stage 2.
>>
>> It's only describe RAM memory, right? If so, this doesn't cover cached PCI
>> bar.
>>
>> Maybe, Linux should ask explicitly to map the region?
>
> I don't think that device memory has a cacheability attribute, does it?
>
> I guess that those cacheable regions would have to be treated as normal
> memory and in any case if we map device memory as normal memory in
> stage2 and the guest maps it as device memory, the resultant type is
> device memory, as it should be.
>
> I don't think we have a problem here.

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


Re: [Xen-devel] [PATCH v2 18/41] arm: Introduce a generic way to use a device from acpi

2015-05-25 Thread Parth Dixit
On 25 May 2015 at 15:30, Julien Grall  wrote:
> Hi Parth,
>
> On 25/05/2015 07:58, Parth Dixit wrote:
>>
>> On 24 May 2015 at 13:10, Julien Grall  wrote:
>>>
>>> On 24/05/2015 08:06, Parth Dixit wrote:
>>>>
>>>>
>>>>   > +struct acpi_device_desc {
>>>>   > +/* Device name */
>>>>   > +const char *name;
>>>>   > +/* Device class */
>>>>   > +enum device_class class;
>>>>   > +/* type of device supported by the driver */
>>>>   > +const int class_type;
>>>>   > +/* Device initialization */
>>>>   > +int (*init)(const void *data);
>>>>   > +};
>>>>
>>>>  Given that the number of device will be minimal in Xen, I would
>>>> prefer
>>>>  to merge this structure into device_desc by adding the ACPI fields.
>>>>
>>>>  It would avoid to duplicate everything for only 2 fields changes.
>>>>
>>>>   From the drivers point of view it would look like
>>>>
>>>>  DEVICE_START()
>>>>   .dt_init = ...
>>>>  #ifdef CONFIG_ACPI
>>>>   .acpi_init = ...
>>>>  #endif
>>>>  DEVICE_END
>>>>
>>>>  Or something like
>>>>
>>>>  DEVICE_START(...)
>>>>   DT_INIT(...)
>>>>   ACPI_INIT(...)
>>>>  DEVICE_END
>>>>
>>>>  And ACPI_INIT will be a no-op when CONFIG_ACPI is not enabled.
>>>>
>>>> I think we agreed not to use common structure as it had some dt specific
>>>> entries and there was scope of confusion.
>>>
>>>
>>>
>>> I don't remember a such agreement. So far, only compatible and init are
>>> DT
>>> specific. The rest (most of the fields) are device agnostic.
>>
>> Adding attachment of the previous discussion
>
>
> Thanks. Please a give link to the conversation (such as a mail archive)
> rather than an attachment. I had to look on the archive to find the context
> of this conversation...
ah, sorry about that, i keep forgetting that this conversation is also
available in public list and i can provide a link to it.
> Also, that something useful to add in the notes of the patch (after ---).
>
> Regards,
>
> --
> Julien Grall

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


Re: [Xen-devel] [PATCH v2 18/41] arm: Introduce a generic way to use a device from acpi

2015-05-24 Thread Parth Dixit
On 24 May 2015 at 13:10, Julien Grall  wrote:
> Hi Parth,
>
>
> On 24/05/2015 08:06, Parth Dixit wrote:
>>
>>  > +struct acpi_device_desc {
>>  > +/* Device name */
>>  > +const char *name;
>>  > +/* Device class */
>>  > +enum device_class class;
>>  > +/* type of device supported by the driver */
>>  > +const int class_type;
>>  > +/* Device initialization */
>>  > +int (*init)(const void *data);
>>  > +};
>>
>> Given that the number of device will be minimal in Xen, I would prefer
>> to merge this structure into device_desc by adding the ACPI fields.
>>
>> It would avoid to duplicate everything for only 2 fields changes.
>>
>>  From the drivers point of view it would look like
>>
>> DEVICE_START()
>>  .dt_init = ...
>> #ifdef CONFIG_ACPI
>>  .acpi_init = ...
>> #endif
>> DEVICE_END
>>
>> Or something like
>>
>> DEVICE_START(...)
>>  DT_INIT(...)
>>  ACPI_INIT(...)
>> DEVICE_END
>>
>> And ACPI_INIT will be a no-op when CONFIG_ACPI is not enabled.
>>
>> I think we agreed not to use common structure as it had some dt specific
>> entries and there was scope of confusion.
>
>
> I don't remember a such agreement. So far, only compatible and init are DT
> specific. The rest (most of the fields) are device agnostic.
Adding attachment of the previous discussion
> If you prefix the DT callback by dt_ (or smth else), there would be
> confusion and a smaller code.
>
> Anyway, I will let Ian and Stefano gives their opinion on it.
>
> Regards,
>
> --
> Julien Grall


Linaro Mail - [PATCH RFC 17_35] pl011_ Initialize serial from ACPI SPCR table.pdf
Description: Adobe PDF document
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table

2015-05-24 Thread Parth Dixit
On 21 May 2015 at 17:11, Julien Grall  wrote:

> On 21/05/15 12:38, Jan Beulich wrote:
>  On 21.05.15 at 12:52,  wrote:
> >> On 21/05/15 11:46, Jan Beulich wrote:
> >> On 21.05.15 at 12:34,  wrote:
>  On 21/05/15 07:22, Jan Beulich wrote:
> > The linked to document (on our wiki) is versioned 0.,
> > which doesn't look like a final stable version. The same applies to
> > the other (STAO?) one.
> 
>  That's a mistake in the version number. Those tables has been reviewed
>  by Citrix and Linaro people and we agreed about the final tables.
> >>>
> >>> And Citriy+Linaro are the standardizing body here? With no-one
> >>> else involved?
> >>
> >> The content of this table is handled by Xen Project and can be modified
> >> at our convenience during the review process.
> >
> > Now that reads as if the table contents and layout are _not_
> > stable yet.
>
> Sorry for been confusing.
>
> > Which seems superseded by 6.0's hypervisor vendor identification
> > in FADT. And the OEM IDs in various table headers could have
> > served such identification purposes too, as could have "OEMx"
> > tables.
> 
>  ACPI 6.0 has been released few months after Parth and Naresh began to
>  implement ACPI for Xen. We could take advantage of this new field.
> >>>
> >>> If at all possible - yes please, in favor of any custom tables.
> >>
> >> It would still be necessary to expose the event channel, grant table
> >> region...
> >
> > Sure, but once you know you run on Xen you could retrieve it via
> > hypercall if there's no other means.
>
> Good point.
>
> ok, so to summarize we are going with hypercall based approach for
retreiving xen env. specific info instead of XENV table?
if yes, i'll remove xenv table and add a new patch for hypercall, please
confirm.

> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 20/41] arm : create generic uart initialization function

2015-05-24 Thread Parth Dixit
On 21 May 2015 at 16:58, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > Rename dt-uart.c to arm-uart.c and create new generic uart init function.
> > move dt_uart_init to uart_init.Refactor pl011 driver to dt and common
> > initialization parts. This will be useful later when acpi specific
> > uart initialization function is introduced.
>
> There is 2 distinct changes in this patch:
> - Introduction of the generic UART
> - Refactoring of PL011
>
> Each changes should be in a separate patch for helping the review.
>
> ok, will move into seperate patches.

> > Signed-off-by: Parth Dixit 
> > ---
> >  xen/arch/arm/setup.c   |   2 +-
> >  xen/drivers/char/Makefile  |   2 +-
> >  xen/drivers/char/dt-uart.c | 107
> -
> >  xen/drivers/char/pl011.c   |  47 
> >  xen/include/xen/serial.h   |   3 +-
> >  5 files changed, 33 insertions(+), 128 deletions(-)
> >  delete mode 100644 xen/drivers/char/dt-uart.c
> >
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 5711077..1b2d74c 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -771,7 +771,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> >
> >  gic_preinit();
> >
> > -dt_uart_init();
> > +uart_init();
>
> As said by Jan, this is arm specific. I would rename into arm_uart_init.
>
> >  console_init_preirq();
> >  console_init_ring();
> >
> > diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> > index 47fc3f9..a8f65c1 100644
> > --- a/xen/drivers/char/Makefile
> > +++ b/xen/drivers/char/Makefile
> > @@ -6,5 +6,5 @@ obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
> >  obj-$(HAS_OMAP) += omap-uart.o
> >  obj-$(HAS_SCIF) += scif-uart.o
> >  obj-$(HAS_EHCI) += ehci-dbgp.o
> > -obj-$(CONFIG_ARM) += dt-uart.o
> > +obj-$(CONFIG_ARM) += arm-uart.o
> >  obj-y += serial.o
>
> > diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> > index 67e6df5..f0c3daf 100644
> > --- a/xen/drivers/char/pl011.c
> > +++ b/xen/drivers/char/pl011.c
> > @@ -225,9 +225,32 @@ static struct uart_driver __read_mostly
> pl011_driver = {
> >  .stop_tx  = pl011_tx_stop,
> >  .vuart_info   = pl011_vuart,
> >  };
> > +static int __init pl011_uart_init(struct pl011 *uart, u64 addr, u64
> size)
> > +{
> > +uart->clock_hz  = 0x16e3600;
> > +uart->baud  = BAUD_AUTO;
> > +uart->data_bits = 8;
> > +uart->parity= PARITY_NONE;
> > +uart->stop_bits = 1;
> > +
> > +uart->regs = ioremap_nocache(addr, size);
> > +if ( !uart->regs )
> > +{
> > +printk("pl011: Unable to map the UART memory\n");
> > +return -ENOMEM;
> > +}
> > +
> > +uart->vuart.base_addr = addr;
> > +uart->vuart.size = size;
> > +uart->vuart.data_off = DR;
> > +uart->vuart.status_off = FR;
> > +uart->vuart.status = 0;
> > +
> > +return 0;
> > +}
> >
> >  /* TODO: Parse UART config from the command line */
> > -static int __init pl011_uart_init(struct dt_device_node *dev,
> > +static int __init dt_pl011_uart_init(struct dt_device_node *dev,
> >const void *data)
> >  {
> >  const char *config = data;
> > @@ -242,12 +265,6 @@ static int __init pl011_uart_init(struct
> dt_device_node *dev,
> >
> >  uart = &pl011_com;
> >
> > -uart->clock_hz  = 0x16e3600;
> > -uart->baud  = BAUD_AUTO;
> > -uart->data_bits = 8;
> > -uart->parity= PARITY_NONE;
> > -uart->stop_bits = 1;
> > -
> >  res = dt_device_get_address(dev, 0, &addr, &size);
> >  if ( res )
> >  {
> > @@ -264,19 +281,13 @@ static int __init pl011_uart_init(struct
> dt_device_node *dev,
> >  }
> >  uart->irq = res;
>
> IRQ can be passed as parameters of pl011_uart_init.
>
> >
> > -uart->regs = ioremap_nocache(addr, size);
> > -if ( !uart->regs )
> > +res = pl011_uart_init(uart, addr, size);
> > +if ( res < 0 )
> >  {
> > -printk("pl011: Unable to map the UART memory\n");
> > -return -ENOMEM;
> > +printk("pl011: Unable to initialize\n");
> > +return res;
> >  }
> >
>

Re: [Xen-devel] [PATCH v2 18/41] arm: Introduce a generic way to use a device from acpi

2015-05-24 Thread Parth Dixit
On 21 May 2015 at 16:49, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > add generic way to use device from acpi similar to
> > the way it is supported in device tree.
> >
> > Signed-off-by: Parth Dixit 
> > ---
> >  xen/arch/arm/device.c| 19 +++
> >  xen/arch/arm/xen.lds.S   |  7 +++
> >  xen/include/asm-arm/device.h | 30 ++
> >  3 files changed, 56 insertions(+)
> >
> > diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
> > index 0b53f6a..5494de0 100644
> > --- a/xen/arch/arm/device.c
> > +++ b/xen/arch/arm/device.c
> > @@ -22,6 +22,7 @@
> >  #include 
> >
> >  extern const struct device_desc _sdevice[], _edevice[];
> > +extern const struct acpi_device_desc _asdevice[], _aedevice[];
> >
> >  int __init device_init(struct dt_device_node *dev, enum device_class
> class,
> > const void *data)
> > @@ -50,6 +51,24 @@ int __init device_init(struct dt_device_node *dev,
> enum device_class class,
> >  return -EBADF;
> >  }
> >
> > +int __init acpi_device_init(enum device_class class, const void *data,
> int class_type)
>
> Please explain what means class_type and how this will fit with every
> ACPI device tables.
>
> AFAICT, it does only works for SPCR table used for UART device. For the
> GIC you've hardcoded the value and I can't find any version number in
> the table.
>
> You may need to introduce another way to find the device such as a
> callback taking the table in parameter.
>
> > +{
> > +const struct acpi_device_desc *desc;
> > +
> > +for ( desc = _asdevice; desc != _aedevice; desc++ )
> > +{
> > +if ( ( desc->class != class ) && ( desc->class_type !=
> class_type ) )
> > +continue;
> > +
> > +
> > +ASSERT(desc->init != NULL);
> > +
> > +return desc->init(data);
> > +}
> > +
> > +return -EBADF;
> > +}
> > +
> >  enum device_class device_get_class(const struct dt_device_node *dev)
> >  {
> >  const struct device_desc *desc;
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 0488f37..60802f6 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -100,6 +100,13 @@ SECTIONS
> >_edevice = .;
> >} :text
> >
> > +  . = ALIGN(8);
> > +  .adev.info : {
> > +  _asdevice = .;
> > +  *(.adev.info)
> > +  _aedevice = .;
> > +  } :text
> > +
> >. = ALIGN(PAGE_SIZE); /* Init code and data */
> >__init_begin = .;
> >.init.text : {
> > diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
> > index a72f7c9..09fcfc3 100644
> > --- a/xen/include/asm-arm/device.h
> > +++ b/xen/include/asm-arm/device.h
> > @@ -50,6 +50,27 @@ struct device_desc {
> >  int (*init)(struct dt_device_node *dev, const void *data);
> >  };
> >
> > +struct acpi_device_desc {
> > +/* Device name */
> > +const char *name;
> > +/* Device class */
> > +enum device_class class;
> > +/* type of device supported by the driver */
> > +const int class_type;
> > +/* Device initialization */
> > +int (*init)(const void *data);
> > +};
>
> Given that the number of device will be minimal in Xen, I would prefer
> to merge this structure into device_desc by adding the ACPI fields.
>
> It would avoid to duplicate everything for only 2 fields changes.
>
> From the drivers point of view it would look like
>
> DEVICE_START()
> .dt_init = ...
> #ifdef CONFIG_ACPI
> .acpi_init = ...
> #endif
> DEVICE_END
>
> Or something like
>
> DEVICE_START(...)
> DT_INIT(...)
> ACPI_INIT(...)
> DEVICE_END
>
> And ACPI_INIT will be a no-op when CONFIG_ACPI is not enabled.
>
> I think we agreed not to use common structure as it had some dt specific
entries and there was scope of confusion.


> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 15/41] arm : acpi parse GTDT to initialize timer

2015-05-24 Thread Parth Dixit
On 20 May 2015 at 23:33, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
> > Using the information presented by GTDT to initialize the arch
> > timer (not memory-mapped).
> >
> > Clear all el2 fields in GTDT table after initialization
> > for passing it to Dom0.
> >
> > Signed-off-by: Naresh Bhat 
> > Signed-off-by: Parth Dixit 
> > ---
> >  xen/arch/arm/acpi/boot.c   | 50
> ++
> >  xen/arch/arm/time.c| 38 +--
> >  xen/include/asm-arm/acpi.h |  2 ++
> >  3 files changed, 79 insertions(+), 11 deletions(-)
> >
> > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> > index 7d9758f..a8311ae 100644
> > --- a/xen/arch/arm/acpi/boot.c
> > +++ b/xen/arch/arm/acpi/boot.c
> > @@ -30,6 +30,8 @@
> >
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  /* Processors with enabled flag and sane MPIDR */
> >  static int enabled_cpus;
> > @@ -40,6 +42,54 @@ static bool_t __initdata bootcpu_valid;
> >  /* arch-optional setting to enable display of offline cpus >=
> nr_cpu_ids */
> >  static unsigned int total_cpus = 0;
> >
> > +/* Initialize per-processor generic timer */
> > +void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[])
>
> acpi/boot.c begin to be a junk room for all ACPI code. It would have
> been more logic to have this code in arch/arm/time.c with proper #ifdef.
>
> This would have drop the generic_timer_irq which is difficult to
> understand.
>
> > +{
> > +int type;
> > +struct acpi_table_gtdt *gtdt=NULL;
>
> *gtdt = NULL;
>
> > +u8 checksum;
> > +static const int GTDT_INTRL_TAB[] =
>
> all uppercase name are used for define.
>
> > +{
> > +ACPI_IRQ_TYPE_LEVEL_HIGH,
> > +ACPI_IRQ_TYPE_EDGE_RISING,
> > +ACPI_IRQ_TYPE_LEVEL_LOW,
> > +ACPI_IRQ_TYPE_EDGE_FALLING
> > +};
>
> It took me a while to understand how this work.
>
> I would prefer an helper which check each field and return/set the
> correct interrupt type.
>
> > +
> > +acpi_get_table(ACPI_SIG_GTDT, 0, (struct acpi_table_header
> **)>dt);
> > +
> > +if( gtdt )
> > +{
>
> If gtdt is NULL you will continue without any warning and potentially
> crash later.
>
> Also please do:
>
> if ( !gtdt ) {
>   /* handle error */
>   return;
> }
>
> /* setup the timer */
>
> It's easier to understand and remove one indentation.
>
> > +/* Initialize all the generic timer IRQ variable from GTDT
> table */
> > +
> > +type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags &
> ACPI_GTDT_INTR_MASK];
> > +set_irq_type(gtdt->non_secure_el1_interrupt, type);
> > +generic_timer_irq[TIMER_PHYS_NONSECURE_PPI] =
> > +gtdt->non_secure_el1_interrupt;
> > +
> > +type = GTDT_INTRL_TAB[gtdt->secure_el1_flags &
> ACPI_GTDT_INTR_MASK];
> > +set_irq_type(gtdt->secure_el1_interrupt, type);
> > +generic_timer_irq[TIMER_PHYS_SECURE_PPI] =
> > +gtdt->secure_el1_interrupt;
> > +
> > +type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags &
> ACPI_GTDT_INTR_MASK];
> > +set_irq_type(gtdt->non_secure_el2_interrupt, type);
> > +generic_timer_irq[TIMER_HYP_PPI] =
> > +gtdt->non_secure_el2_interrupt;
> > +
> > +type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags &
> ACPI_GTDT_INTR_MASK];
> > +set_irq_type(gtdt->virtual_timer_interrupt, type);
> > +generic_timer_irq[TIMER_VIRT_PPI] =
> > +gtdt->virtual_timer_interrupt;
> > +
> > +gtdt->non_secure_el2_interrupt = 0;
> > +gtdt->non_secure_el2_flags = 0;
> > +checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, gtdt),
> gtdt->header.length);
> > +gtdt->header.checksum -= checksum;
> > +clean_dcache_va_range(gtdt, sizeof(struct acpi_table_gtdt));
>
> Similar comment as on the MADT, this function is initializing the timer
> and not modifying the ACPI table.
>
> I would prefer a separate function which is called during DOM0 building.
> It would be easier to know how the ACPI table has been modified for DOM0.
>
> Also, please add a comment to explain this block smth like /* Hide EL2
> interrupt to DOM0 */. M

Re: [Xen-devel] [PATCH v2 05/41] acpi : add helper function for mapping memory

2015-05-23 Thread Parth Dixit
On 18 May 2015 at 18:56, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> > index 935999e..096e9ef 100644
> > --- a/xen/arch/arm/Makefile
> > +++ b/xen/arch/arm/Makefile
> > @@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
> >  subdir-$(arm64) += arm64
> >  subdir-y += platforms
> >  subdir-$(arm64) += efi
> > +subdir-$(HAS_ACPI) += acpi
> >
> >  obj-$(EARLY_PRINTK) += early_printk.o
> >  obj-y += cpu.o
> > diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
> > new file mode 100644
> > index 000..b5be22d
> > --- /dev/null
> > +++ b/xen/arch/arm/acpi/Makefile
> > @@ -0,0 +1 @@
> > +obj-y += lib.o
> > diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
> > new file mode 100644
> > index 000..650beed
> > --- /dev/null
> > +++ b/xen/arch/arm/acpi/lib.c
> > @@ -0,0 +1,8 @@
> > +#include 
> > +#include 
> > +
> > +void __iomem *
> > +acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> > +{
> > +return __va(phys);
> > +}
>
> I would have prefer two distinct patch: one for the refactoring of
> acpi_os_map_memory and the other for implementing the ARM part
> explaining why only using __va.
>
> __va should only be used when the memory is direct-mapped to Xen (i.e
> accessible directly). On ARM64, this only the case for the RAM. Can you
> confirm that ACPI will always reside to the RAM?
>
> I already asked the same question on the previous version but got no
> answer from you...
>
> I did not found any document which says it will always reside in RAM or
otherwise..

> >  /*
> >   * Important Safety Note:  The fixed ACPI page numbers are *subtracted*
> >   * from the fixed base.  That's why we start at FIX_ACPI_END and
> > diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> > index 93c983c..958caae 100644
> > --- a/xen/drivers/acpi/osl.c
> > +++ b/xen/drivers/acpi/osl.c
> > @@ -87,16 +87,7 @@ acpi_physical_address __init
> acpi_os_get_root_pointer(void)
> >  void __iomem *
> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> >  {
> > - if (system_state >= SYS_STATE_active) {
> > - unsigned long pfn = PFN_DOWN(phys);
> > - unsigned int offs = phys & (PAGE_SIZE - 1);
> > -
> > - /* The low first Mb is always mapped. */
> > - if ( !((phys + size - 1) >> 20) )
> > - return __va(phys);
> > - return __vmap(&pfn, PFN_UP(offs + size), 1, 1,
> PAGE_HYPERVISOR_NOCACHE) + offs;
> > - }
> > - return __acpi_map_table(phys, size);
> > +return acpi_os_map_iomem(phys, size);
>
> The naming is wrong. It's really hard to differentiate
> acpi_os_map_memory from acpi_os_map_iomem. I would rename to something
> more meaningful such as arch_acpi_os_map_memory.
>
> Although, given that acpi_os_map_memory only call acpi_os_map_iomem. I
> would move acpi_os_map_memory per-architecture. FWIW, it's what Linux does.
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


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

2015-05-23 Thread Parth Dixit
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?

> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 02/41] arm/acpi: Build pmstat for x86 only

2015-05-23 Thread Parth Dixit
On 20 May 2015 at 20:42, Jan Beulich  wrote:

> >>> On 17.05.15 at 22:03,  wrote:
> > Pmstat is currently not supported for arm in xen.
> > Configure and build pmstat for x86 architecture only.
>
> Same here as for patch 1. If the architecture can be expected to
> eventually support a feature, I'd generally prefer the architecture
> to get necessary stubs added over fiddling with common code.
>
> ok, will add stubs in next patchset.

> > --- a/xen/common/sysctl.c
> > +++ b/xen/common/sysctl.c
> > @@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
> >  op->u.availheap.avail_bytes <<= PAGE_SHIFT;
> >  break;
> >
> > +#ifdef CONFIG_X86
> >  #ifdef HAS_ACPI
> >  case XEN_SYSCTL_get_pmstat:
> >  ret = do_get_pm_info(&op->u.get_pmstat);
>
> Please fold the two #if-s into one, or even replace the HAS_ACPI
> one if this really needs to be done.
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 10/41] arm/acpi : Print GIC information when MADT is parsed

2015-05-23 Thread Parth Dixit
On 18 May 2015 at 20:36, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > From: Naresh Bhat 
> >
> > When MADT is parsed, print GIC information to make the boot
> > log look pretty.
> >
> > Signed-off-by: Hanjun Guo 
> > Signed-off-by: Tomasz Nowicki 
> > Signed-off-by: Naresh Bhat 
> > ---
> >  xen/drivers/acpi/tables.c | 39 +++
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
> > index 1beca79..684d8c9 100644
> > --- a/xen/drivers/acpi/tables.c
> > +++ b/xen/drivers/acpi/tables.c
> > @@ -190,6 +190,45 @@ void __init acpi_table_print_madt_entry(struct
> acpi_subtable_header *header)
> >   }
> >   break;
> >
> > +case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
> > +{
> > +struct acpi_madt_generic_interrupt *p =
> > +(struct acpi_madt_generic_interrupt *)header;
> > +printk(KERN_INFO PREFIX
> > +"GIC (acpi_id[0x%04x] gic_id[0x%04x] %s)\n",
> > +p->uid, p->gic_id,
> > +(p->flags & ACPI_MADT_ENABLED) ? "enabled" :
> "disabled");
>
> Printk indentation:
>
> printk(KERN_INFO PREFIX
>"GIC ...
>...);
>
> Also, it seems that the indentation doesn't match the rest of the switch
> case.
>
> > +}
> > +break;
> > +
> > +case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
> > +{
> > +struct acpi_madt_generic_distributor *p =
> > +(struct acpi_madt_generic_distributor *)header;
> > +printk(KERN_INFO PREFIX
> > +"GIC Distributor (id[0x%04x] address[0x%08llx]
> gsi_base[%d])\n",
> > +p->gic_id, (long long unsigned int)p->base_address,
> p->global_irq_base);
>
> Ditto
>
> > +}
> > +break;
> > +
> > +case ACPI_MADT_TYPE_GIC_MSI_FRAME:
> > +{
> > +struct acpi_madt_gic_msi_frame *p =
> > +(struct acpi_madt_gic_msi_frame *)header;
> > +printk("GIC MSI Frame (address[0x%08llx]
> msi_fame_id[%d])\n",
> > +(long long unsigned int)p->base_address,
> p->gic_msi_frame_id);
>
> Ditto & missing KERN_INFO PREFIX
>
> > +}
> > +break;
> > +
> > +case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
> > +{
> > +struct acpi_madt_gic_redistributor *p =
> > +(struct acpi_madt_gic_redistributor *)header;
> > +printk("GIC Redistributor (address[0x%08llx]
> region_size[0x%x])\n",
> > +(long long unsigned int)p->base_address,
> p->region_size);
>
> Ditto & missing KERN_INFO PREFIX
>
 will take care in next patchset.

>
> > +}
> > +break;
> > +
> >   default:
> >   printk(KERN_WARNING PREFIX
> >  "Found unsupported MADT entry (type = %#x)\n",
> >
>
> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 11/41] arm/acpi : add GTDT support updated by ACPI 5.1

2015-05-23 Thread Parth Dixit
On 18 May 2015 at 20:41, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > With ACPI 5.0, we got per-processor timer support in GTDT,
> > and ACPI 5.1 introduced the support for platform (memory-mapped)
> > timers: GT Block and SBSA watchdog timer, add the code needed
> > for the spec change.
> >
> > Signed-off-by: Hanjun Guo 
> > Signed-off-by: Naresh Bhat 
> > Signed-off-by: Parth Dixit 
> > ---
> >  xen/include/acpi/actbl3.h  | 92
> +++---
> >  xen/include/asm-arm/acpi.h |  2 +
> >  2 files changed, 80 insertions(+), 14 deletions(-)
> >
> > diff --git a/xen/include/acpi/actbl3.h b/xen/include/acpi/actbl3.h
> > index 8c61b5f..7664f9d 100644
> > --- a/xen/include/acpi/actbl3.h
> > +++ b/xen/include/acpi/actbl3.h
> > @@ -241,33 +241,97 @@ struct acpi_s3pt_suspend {
> >
> >
> /***
> >   *
> > - * GTDT - Generic Timer Description Table (ACPI 5.0)
> > + * GTDT - Generic Timer Description Table (ACPI 5.1)
> >   *Version 1
> >   *
> >
>  
> **/
> >
> >  struct acpi_table_gtdt {
> >   struct acpi_table_header header;/* Common ACPI table
> header */
> > - u64 address;
> > - u32 flags;
> > - u32 secure_pl1_interrupt;
> > - u32 secure_pl1_flags;
> > - u32 non_secure_pl1_interrupt;
> > - u32 non_secure_pl1_flags;
> > + u64 cnt_control_base_address;
>
> This patch is out-of-sync compare to the Linux one (naming different,
> comment...). Can you update it?
>
> sure, i'll take care in next patchset.

> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 08/41] arm/acpi : Parse FADT table and get PSCI flags

2015-05-23 Thread Parth Dixit
On 18 May 2015 at 20:28, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> > the former signals to the OS that the hardware is PSCI compliant.
> > The latter selects the appropriate conduit for PSCI calls by
> > toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> > (SMC).
> >
> > FADT table contains such information, parse FADT to get the flags
> > for furture usage. At the same time, only ACPI 5.1 or higher verison
> > supports PSCI, and FADT Major.Minor version was introduced in ACPI
> > 5.1, so we will check the version and only parse FADT table with
> > version >= 5.1.
> >
> > If firmware provides ACPI tables with ACPI version less than 5.1,
> > OS will be messed up with those information, so disable ACPI if we
> > get an FADT table with version less that 5.1.
> >
> > Modify FADT table before passing it to Dom0.
> > Set PSCI_COMPLIANT and PSCI_USE_HVC.
> >
> > Signed-off-by: Hanjun Guo 
> > Signed-off-by: Naresh Bhat 
> > Signed-off-by: Parth Dixit 
> > ---
> >  xen/arch/arm/acpi/boot.c   | 38 ++
> >  xen/arch/arm/acpi/lib.c| 11 +++
> >  xen/include/asm-arm/acpi.h | 11 +++
> >  3 files changed, 60 insertions(+)
> >
> > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> > index 8dc69d5..57eb33c 100644
> > --- a/xen/arch/arm/acpi/boot.c
> > +++ b/xen/arch/arm/acpi/boot.c
> > @@ -24,9 +24,40 @@
> >
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >
> >  #include 
> >
> > +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> > +{
> > +struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> > +u8 checksum;
> > +
> > +/*
> > + * Revision in table header is the FADT Major revision, and there
> > + * is a minor revision of FADT which was introduced by ACPI 5.1,
> > + * we only deal with ACPI 5.1 or newer revision to get GIC and SMP
> > + * boot protocol configuration data, or we will disable ACPI.
> > + */
> > +if ( table->revision > 5 ||
> > +( table->revision == 5 && fadt->minor_revision >= 1 ) )
>
> The indentation looks wrong here.
>
> > +{
> > +fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT |
> ACPI_FADT_PSCI_USE_HVC );
> > +checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt),
> fadt->header.length);
> > +fadt->header.checksum -= checksum;
> > +clean_dcache_va_range(fadt, sizeof(struct acpi_table_fadt));
>
> Most of this patch is dealing with setting up correctly DOM0 FADT
> although the title doesn't mention it and there is only 2 lines in the
> commit message. This would also need comment in the need explaining what
> this code does.
>
> Furthermore, I don't think this code should live here. The function is
> called by acpi_boot_table_init which should initialize ACPI and not
> trying to modify the ACPI table.
>
> i'll split it into two patches with modifying of fadt going into seperate
patch.

> We should have a specific dom0 acpi function to modify/add ACPI table
> when it's necessary.
>
> > +return 0;
> > +}
> > +
> > +printk("Unsupported FADT revision %d.%d, should be 5.1+, will
> disable ACPI\n",
> > +table->revision, fadt->minor_revision);
> > +disable_acpi();
> > +
> > +return -EINVAL;
> > +}
> > +
> >  /*
> >   * acpi_boot_table_init() called from setup_arch(), always.
> >   *  1. find RSDP and get its address, and then find XSDT
> > @@ -51,6 +82,13 @@ int __init acpi_boot_table_init(void)
> >  return error;
> >  }
> >
> > +if ( acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt) )
> > +{
> > +/* disable ACPI if no FADT is found */
> > +disable_acpi();
> > +printk("Can't find FADT\n");
> > +}
> > +
>
> I think the code readability will be improved if we introduce
> acpi_get_table_with_size.
>
> Although, this is not implemented by ACPICA but only Linux. Jan may not
> be agree to import it.
>
> >  return 0;
> >  }
> >
> > diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
> > index 650beed..fd9bfa4 100644
> > --- a/xen/arch/arm/acpi/lib.c
> > +++ b/xen/arch

Re: [Xen-devel] [PATCH v2 07/41] arm/acpi : Introduce ARM Boot Architecture Flags in FADT

2015-05-23 Thread Parth Dixit
On 18 May 2015 at 19:59, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > The Power State Coordination Interface (PSCI) defines an API that
> > can be used to coordinate power control amongst the various supervisory
> > systems concurrently running on a device. ACPI support for this
> > technology would require the addition of two flags: PSCI_COMPLIANT and
> > PSCI_USE_HVC. When set, the former signals to the OS that the hardware
> > is PSCI compliant. The latter selects the appropriate conduit for PSCI
> > calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
> > Calls (SMC).
> >
> > An ARM Boot Architecture Flags structure to support new ARM hardware
> > was introduced in FADT in ACPI 5.1, add the code accordingly to
> > implement that in ACPICA core.
> >
> > Since ACPI 5.1 doesn't support self defined PSCI function IDs,
> > which means that only PSCI 0.2+ is supported in ACPI.
> >
> > Signed-off-by: Hanjun Guo 
> > Signed-off-by: Naresh Bhat 
> > ---
> >  xen/include/acpi/actbl.h | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
> > index 856945d..96fd1d8 100644
> > --- a/xen/include/acpi/actbl.h
> > +++ b/xen/include/acpi/actbl.h
> > @@ -244,7 +244,8 @@ struct acpi_table_fadt {
> >   u32 flags;  /* Miscellaneous flag bits (see below for
> individual flags) */
> >   struct acpi_generic_address reset_register; /* 64-bit address
> of the Reset register */
> >   u8 reset_value; /* Value to write to the reset_register
> port to reset the system */
> > - u8 reserved4[3];/* Reserved, must be zero */
> > +u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below
> for individual flags) */
> > +u8 minor_revision;   /* Minor version of this FADT structure */
>
> Wrong indentation. The file is using hard tab.
>
> >   u64 Xfacs;  /* 64-bit physical address of FACS */
> >   u64 Xdsdt;  /* 64-bit physical address of DSDT */
> >   struct acpi_generic_address xpm1a_event_block;  /* 64-bit Extended
> Power Mgt 1a Event Reg Blk address */
> > @@ -270,6 +271,11 @@ struct acpi_table_fadt {
> >
> >  #define FADT2_REVISION_ID   3
> >
> > +/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
> > +
> > +#define ACPI_FADT_PSCI_COMPLIANT(1)/* 00: PSCI 0.2+ is
> implemented */
> > +#define ACPI_FADT_PSCI_USE_HVC  (1<<1) /* 01: HVC must be used
> instead of SMC as the PSCI conduit */
> > +
> >  /* Masks for FADT flags */
> >
> >  #define ACPI_FADT_WBINVD(1)  /* 00: [V1] The wbinvd
> instruction works properly */
> > @@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
> >   * FADT V5  size: 0x10C
> >   */
> >  #define ACPI_FADT_V1_SIZE   (u32) (ACPI_FADT_OFFSET (flags) + 4)
> > -#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (reserved4[0])
> + 3)
> > +#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET
> (arm_boot_flags) + 3)
>
> Linux is using ACPI_FADT_OFFSET(minor_revision) + 1. Can you use the
> same here?
>
> Also, I've notice that the patch (see 9eb1105) is slightly different.
> Mostly documenting the ACPI version for the fields.
>
> Can you update the patch based on Linux code to use the latest version
> (i.e the version upstreamed)?
>
> sure, i'll update it to be in sync with linux.

> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 06/41] arm/acpi : Add basic ACPI initialization

2015-05-23 Thread Parth Dixit
On 18 May 2015 at 19:41, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > acpi_boot_table_init() will be called in start_xen
> > to get the RSDP and all the table pointers. with this patch,
> > we can get ACPI boot-time tables from firmware on ARM64.
> >
> > Signed-off-by: Naresh Bhat 
> > Signed-off-by: Parth Dixit 
> > ---
> >  xen/arch/arm/acpi/Makefile |  1 +
> >  xen/arch/arm/acpi/boot.c   | 56
> ++
> >  xen/arch/arm/setup.c   | 13 +--
> >  3 files changed, 68 insertions(+), 2 deletions(-)
> >  create mode 100644 xen/arch/arm/acpi/boot.c
> >
> > diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
> > index b5be22d..196c40a 100644
> > --- a/xen/arch/arm/acpi/Makefile
> > +++ b/xen/arch/arm/acpi/Makefile
> > @@ -1 +1,2 @@
> >  obj-y += lib.o
> > +obj-y += boot.o
> > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> > new file mode 100644
> > index 000..8dc69d5
> > --- /dev/null
> > +++ b/xen/arch/arm/acpi/boot.c
> > @@ -0,0 +1,56 @@
> > +/*
> > + *  ARM64 Specific Low-Level ACPI Boot Support
>
> This code is not ARM64 specific:
>
> s/ARM64/ARM/
>
> > + *
> > + *  Copyright (C) 2014, Naresh Bhat 
>
> The code within this file is a copy of arch/x86/acpi/boot.c.
>
> Please retain the copyright and add yours if necessary.
>
> > + *
> > + *
> ~~
> > + *
> > + *  This program is free software; you can redistribute it and/or modify
> > + *  it under the terms of the GNU General Public License as published by
> > + *  the Free Software Foundation; either version 2 of the License, or
> > + *  (at your option) any later version.
> > + *
> > + *  This program is distributed in the hope that it will be useful,
> > + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + *  GNU General Public License for more details.
> > + *
> > + *  You should have received a copy of the GNU General Public License
> > + *  along with this program; if not, write to the Free Software
> > + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> 02111-1307  USA
> > + *
> > + *
> ~~
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +/*
> > + * acpi_boot_table_init() called from setup_arch(), always.
> > + *  1. find RSDP and get its address, and then find XSDT
> > + *  2. extract all tables and checksums them all
> > + *
> > + * We can parse ACPI boot-time tables such as FADT, MADT after
> > + * this function is called.
>
> It's worth to expand the commit message as done in the x86 version
> to explain the return value.
>
> > + */
> > +int __init acpi_boot_table_init(void)
> > +{
> > +int error;
> > +
> > +/* If acpi_disabled, bail out */
> > +if ( acpi_disabled )
> > +return 1;
> > +
> > +/* Initialize the ACPI boot-time table parser. */
> > +error = acpi_table_init();
>
> I didn't find a better place for this comment. Though it's related to
> the ACPI initialization...
>
> You need to change_acpi_os_get_root_pointer, the current behavior is to
> fallback on the legacy method (i.e scanning the first MB of memory) when
> efi_enabled 0.
>
> sure, will take care in next patchset.

> > +if ( error )
> > +{
> > +disable_acpi();
> > +return error;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 06f8e54..5711077 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -36,6 +36,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -45,10 +46,12 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  struct bootinfo __initdata bootinfo;
> >
> >  struct cpuinfo_arm __read_mostly boot_cpu_data;
> > +bool_t acpi_disabled;
> >
> >  #ifdef CONFIG_ARM_32
> >  static unsigned long opt_xenheap_megabytes __initdata;
> > @@ -610,7 +613,6 @@ static void __init setup_mm(unsigned long dtb_paddr,
> size_t

Re: [Xen-devel] [PATCH v2 04/41] arm/acpi : add arm specific acpi header file

2015-05-23 Thread Parth Dixit
On 18 May 2015 at 18:42, Julien Grall  wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > +#ifndef _ASM_ARM64_ACPI_H
> > +#define _ASM_ARM64_ACPI_H
>
> s/_ASM_ARM64_ACPI_H/_ASM_ARM_ACPI_H/
>
> > +
> > +#include 
> > +
> > +#define COMPILER_DEPENDENT_INT64   long long
> > +#define COMPILER_DEPENDENT_UINT64  unsigned long long
> > +
> > +extern bool_t acpi_disabled;
> > +/* Basic configuration for ACPI */
> > +static inline void disable_acpi(void)
> > +{
> > +acpi_disabled = 1;
> > +}
>
> It makes a little sense to add the prototype of acpi_disabled without
> effectively declaring it.
>
> Also, the code is very similar to the x86. It would make sense to
> factorize it (disable_acpi, acpi parameters...) in a common place.
>
> sure, i will take care in next patch set.

> > +#endif /*_ASM_ARM_ACPI_H*/
> >
>
> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 16/41] acpi : Introduce acpi_parse_entries

2015-05-21 Thread Parth Dixit
On 20 May 2015 at 21:43, Jan Beulich  wrote:

> >>> On 17.05.15 at 22:03,  wrote:
> > add new function acpi_parse_entries which takes
> > acpi table as argument. This will avoid fetching table
> > everytime in acpi_table_parse_entries.
>
> This explanation doesn't make a lot of sense to me - I don't see you
> save anything. Am I missing anything? Are you intending to use the
> new function separately? Also, please don't break indentation like
>
yes, i am fetching the table once and parsing it with this function in
acpi_gicv2_init function in the patch given below
http://lists.xen.org/archives/html/xen-devel/2015-05/msg02208.html

> you do here (and elsewhere).
>
> sure, i'll take care of the indentation.

> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2 00/41] Add ACPI support for arm64 on Xen

2015-05-18 Thread Parth Dixit
On 18 May 2015 at 13:55, Jan Beulich  wrote:

> >>> On 17.05.15 at 22:03,  wrote:
> > Naresh Bhat (3):
> >   arm/acpi: Build numa for x86 only
> >   arm/acpi : Print GIC information when MADT is parsed
> >   xen: arm64: Add ACPI support
> >
> > Parth Dixit (38):
> >   arm/acpi: Build pmstat for x86 only
> >   arm/acpi : emulate io ports for arm
> >   arm/acpi : add arm specific acpi header file
> >   acpi : add helper function for mapping memory
> >   arm/acpi : Add basic ACPI initialization
> >   arm/acpi : Introduce ARM Boot Architecture Flags in  FADT
> >   arm/acpi : Parse FADT table and get PSCI flags
> >   arm/acpi : Add Generic Interrupt and Distributor struct
> >   arm/acpi : add GTDT support updated by ACPI 5.1
> >   arm : move dt specific code in smp to seperate  functions
> >   arm/acpi : parse MADT to map logical cpu to MPIDR and  get
> > cpu_possible_map
> >   arm : acpi add helper function for setting interrupt  type
> >   arm : acpi parse GTDT to initialize timer
> >   acpi : Introduce acpi_parse_entries
> >   arm : refactor gic into generic and dt specific parts
> >   arm: Introduce a generic way to use a device from acpi
> >   arm : acpi Add GIC specific ACPI boot support
> >   arm : create generic uart initialization function
> >   arm : acpi Initialize serial port from ACPI SPCR table
> >   arm : acpi create min DT stub for DOM0
> >   arm : acpi create chosen node for DOM0
> >   arm : acpi create efi node for DOM0
> >   arm : acpi add status override table
> >   arm : acpi add xen environment table
> >   arm : add helper functions to map memory regions
> >   arm : acpi add efi structures to common efi header
> >   arm : acpi read acpi memory info from uefi
> >   arm : acpi add placeholder for acpi load address
> >   arm : acpi estimate memory required for acpi/efi tables
> >   arm : acpi dynamically map mmio regions
> >   arm : acpi prepare acpi tables for dom0
> >   arm : acpi create and map acpi tables
> >   arm : acpi add helper function to calculate crc32
> >   arm : acpi pass rsdp and memory via efi table
> >   arm : acpi add acpi parameter to enable/disable acpi
> >   arm : acpi enable efi for acpi
> >   arm : acpi configure interrupts dynamically
> >   arm : acpi route irq's at time of boot
>
> Please trim your Cc list on the individual patches, i.e. avoid Cc-ing
> every maintainer involved in some of the patches one every one of
> them. In the case here, only 16 of the 41 patches really need me
> looking at them.
>
> Jan
>
> sure, sorry for the trouble, i'll take care in future.
regards
parth
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [PATCH v2 38/41] arm : acpi enable efi for acpi

2015-05-17 Thread Parth Dixit
efi should be enabled to fetch the root pointer from uefi

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/setup.c | 2 ++
 xen/common/efi/runtime.c | 2 +-
 xen/include/xen/efi.h| 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 80364bb..9741113 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bootinfo __initdata bootinfo;
 
@@ -104,6 +105,7 @@ static void __init parse_acpi_param(char *s)
 else if ( !strcmp(s, "force") )
 {
 acpi_disabled = 0;
+efi_enabled = 1;
 }
 }
 #endif
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 5ed8b01..fb8c0d0 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -11,7 +11,7 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
 #ifndef COMPAT
 
 #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
-const bool_t efi_enabled = 0;
+bool_t efi_enabled = 0;
 #else
 # include 
 # include 
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 9fdc72b..448d41d 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -5,7 +5,7 @@
 #include 
 #endif
 
-extern const bool_t efi_enabled;
+extern bool_t efi_enabled;
 
 #define EFI_INVALID_TABLE_ADDR (~0UL)
 #define EFI_MEM_DESC_V1 1
-- 
1.9.1


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


[Xen-devel] [PATCH v2 39/41] arm : acpi configure interrupts dynamically

2015-05-17 Thread Parth Dixit
Interrupt information is described in DSDT and is not available at
the time of booting. Configure the interrupts dynamically when requested
by Dom0

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/vgic.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 73a6f7e..f63deb4 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -285,6 +286,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
 }
 }
 
+#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
+
 void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 {
 struct domain *d = v->domain;
@@ -296,7 +299,22 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 struct vcpu *v_target;
 
 while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
+#ifdef CONFIG_ACPI
+struct vgic_irq_rank *vr = vgic_get_rank(v, n);
+uint32_t tr;
+irq = i + (32 * n);
+if( ( !acpi_disabled ) && ( n != 0 ) && is_hardware_domain(d) )
+{
+tr = vr->icfg[i >> 4] ;
+
+if( ( tr & VGIC_ICFG_MASK(i) ) )
+set_irq_type(irq, ACPI_IRQ_TYPE_EDGE_BOTH);
+else
+set_irq_type(irq, ACPI_IRQ_TYPE_LEVEL_MASK);
+}
+#else
 irq = i + (32 * n);
+#endif
 v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
 p = irq_to_pending(v_target, irq);
 set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
-- 
1.9.1


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


[Xen-devel] [PATCH v2 37/41] arm : acpi add acpi parameter to enable/disable acpi

2015-05-17 Thread Parth Dixit
ACPI will be disabled by default. Define new
command line parameter "acpi" for enabling it.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/setup.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1b2d74c..80364bb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -58,6 +58,12 @@ static unsigned long opt_xenheap_megabytes __initdata;
 integer_param("xenheap_megabytes", opt_xenheap_megabytes);
 #endif
 
+#ifdef CONFIG_ACPI
+/* "acpi=force" : Enables acpi */
+static void parse_acpi_param(char *s);
+custom_param("acpi", parse_acpi_param);
+#endif
+
 static __used void init_done(void)
 {
 free_init_memory();
@@ -83,6 +89,25 @@ static const char * __initdata processor_implementers[] = {
 ['i'] = "Intel Corporation",
 };
 
+#ifdef CONFIG_ACPI
+static char __initdata acpi_param[10] = "";
+static void __init parse_acpi_param(char *s)
+{
+/* Save the parameter so it can be propagated to domain0. */
+safe_strcpy(acpi_param, s);
+
+/* Interpret the parameter for use within Xen. */
+if ( !parse_bool(s) )
+{
+disable_acpi();
+}
+else if ( !strcmp(s, "force") )
+{
+acpi_disabled = 0;
+}
+}
+#endif
+
 static void __init processor_id(void)
 {
 const char *implementer = "Unknown";
@@ -731,6 +756,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 + (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
 fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
 
+disable_acpi();
 cmdline = boot_fdt_cmdline(device_tree_flattened);
 printk("Command line: %s\n", cmdline);
 cmdline_parse(cmdline);
-- 
1.9.1


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


[Xen-devel] [PATCH v2 40/41] xen: arm64: Add ACPI support

2015-05-17 Thread Parth Dixit
From: Naresh Bhat 

Add ACPI support on arm64 xen hypervisor.

Signed-off-by: Naresh Bhat 
---
 config/arm64.mk  | 1 +
 xen/include/asm-arm/config.h | 5 +
 2 files changed, 6 insertions(+)

diff --git a/config/arm64.mk b/config/arm64.mk
index e24c1d1..bce9107 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -10,6 +10,7 @@ HAS_PL011 := y
 HAS_CADENCE_UART := y
 HAS_NS16550 := y
 HAS_MEM_ACCESS := y
+HAS_ACPI := y
 
 # Use only if calling $(LD) directly.
 LDFLAGS_DIRECT += -EL
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 3b23e05..0170925 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -33,6 +33,11 @@
 
 #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
 
+#if defined(CONFIG_ARM_64)
+#define CONFIG_ACPI 1
+#define CONFIG_ACPI_BOOT 1
+#endif
+
 #define CONFIG_SMP 1
 
 #define CONFIG_VIDEO 1
-- 
1.9.1


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


[Xen-devel] [PATCH v2 41/41] arm : acpi route irq's at time of boot

2015-05-17 Thread Parth Dixit
NOTE: This is a wrokaround to be fixed later.
Route all the irq's to Dom0 at the time of booting.
Trigger and polarity will be set dyanmaically when
Dom0 request's for it.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2ce30bf..cdad86b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1481,6 +1481,26 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo, struct memb
 acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp) );
 
 prepare_efi_table(d, kinfo, tbl_add);
+
+/* configure interrupts gicv2 only */
+ for( i = 32 ; i < 255 ; i++ )
+ {
+struct irq_desc *desc;
+desc = irq_to_desc(i);
+if( desc->action != NULL)
+continue;
+
+vgic_reserve_virq(d, i);
+set_irq_type(i, ACPI_IRQ_TYPE_NONE);
+res = route_irq_to_guest(d, i, i, NULL);
+if ( res )
+{
+printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
+i, d->domain_id);
+continue;
+}
+ }
+
 /* map rsdp table */
 size = sizeof(struct acpi_table_rsdp);
 
-- 
1.9.1


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


[Xen-devel] [PATCH v2 36/41] arm : acpi pass rsdp and memory via efi table

2015-05-17 Thread Parth Dixit
Create EFI table and populate it with DOM0 memory and address
of RSDP. Fix device tree with correct addresses of EFI table
and start of memory descriptor address.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 106 
 1 file changed, 106 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0ad70c1..2ce30bf 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1260,6 +1260,111 @@ static uint32_t xz_crc32(uint8_t *buf, size_t size, 
uint32_t crc)
return ~crc;
 }
 
+static int prepare_efi_table(struct domain *d,
+  const struct kernel_info *kinfo,
+   struct membank tbl_add[])
+{
+u64 fdt_val64;
+u32 fdt_val32;
+int size;
+int i,offset;
+unsigned long res;
+int node;
+u16 *fw_vendor;
+u8 *base_ptr;
+struct efi_memory_desc *memory_map;
+struct efi_config_table *acpi_ect;
+struct efi_system_table *sys_tbl;
+void * __user tbl_virt = (void * __user)(register_t)kinfo->acpi_paddr;
+struct efi_system_table *efi_sys_tbl = ( struct efi_system_table *)
+maddr_to_virt(efi.est);
+
+xz_crc32_init();
+/* Fix up linux,uefi-system-table and linux,mmap-size in /chosen */
+node = fdt_path_offset(kinfo->fdt, "/chosen");
+if ( node < 0 )
+panic("Cannot find the /chosen node");
+
+size = tbl_add[TBL_EFIT].size
++  tbl_add[TBL_MMAP].size;
+
+tbl_virt += get_acpi_size();
+base_ptr = xzalloc_bytes(size);
+sys_tbl = (struct efi_system_table *)base_ptr;
+memcpy( (struct efi_table_hdr*)&(sys_tbl->hdr),
+(struct efi_table_hdr*)&(efi_sys_tbl->hdr),
+sizeof(struct efi_table_hdr) );
+sys_tbl->hdr.headersize = tbl_add[TBL_EFIT].size;
+
+sys_tbl->fw_revision = efi_sys_tbl->fw_revision;
+sys_tbl->nr_tables = 1;
+fdt_val64 = cpu_to_fdt64((u64)(uintptr_t)tbl_virt);
+res = fdt_setprop_inplace(kinfo->fdt, node, "linux,uefi-system-table",
+  &fdt_val64, sizeof(fdt_val64));
+if ( res )
+return res;
+offset = sizeof(struct efi_system_table);
+
+size = sizeof(XEN_EFI_FW_VENDOR);
+fw_vendor = (u16 *)(base_ptr+offset);
+memcpy(fw_vendor, XEN_EFI_FW_VENDOR, size);
+sys_tbl->fw_vendor = (u64)(tbl_virt+offset);
+offset+=size;
+
+size = sizeof(struct efi_config_table);
+acpi_ect = (struct efi_config_table *)(base_ptr+offset);
+acpi_ect->guid = ACPI_20_TBL_GUID;
+acpi_ect->table = efi.acpi20;
+sys_tbl->tables = (u64)(tbl_virt+offset);
+offset += size;
+sys_tbl->hdr.crc32 = xz_crc32((uint8_t *)sys_tbl, sys_tbl->hdr.headersize, 
0);
+
+size = tbl_add[TBL_MMAP].size;
+memory_map = (struct efi_memory_desc *)(base_ptr+offset);
+fdt_val64 = cpu_to_fdt64((u64)(uintptr_t)(tbl_virt+offset));
+res = fdt_setprop_inplace(kinfo->fdt, node, "linux,uefi-mmap-start",
+  &fdt_val64,  sizeof(fdt_val64));
+if ( res )
+return res;
+
+fdt_val32 = cpu_to_fdt32(size);
+res = fdt_setprop_inplace(kinfo->fdt, node, "linux,uefi-mmap-size",
+  &fdt_val32,  sizeof(fdt_val32));
+size += offset;
+
+for( i=0; i < kinfo->mem.nr_banks ; i++)
+{
+memory_map[i].type = EFI_CONVENTIONAL_MEMORY;
+memory_map[i].phys_addr = kinfo->mem.bank[i].start;
+memory_map[i].num_pages = kinfo->mem.bank[i].size/PAGE_SIZE;
+memory_map[i].attribute |= EFI_MEMORY_ATT_WB;
+}
+offset = kinfo->mem.nr_banks;
+for( i=0; i < acpi_mem.nr_banks ; i++,offset++)
+{
+memory_map[offset].type = EFI_ACPI_RECLAIM_MEMORY;
+memory_map[offset].phys_addr = acpi_mem.bank[i].start;
+memory_map[offset].num_pages = acpi_mem.bank[i].size/PAGE_SIZE;
+}
+
+for( i=0; i < TBL_MMAX; i++, offset++ )
+{
+memory_map[offset].type = EFI_ACPI_RECLAIM_MEMORY;
+memory_map[offset].phys_addr = tbl_add[i].start;
+memory_map[offset].num_pages =tbl_add[i].size/PAGE_SIZE;
+memory_map[i].attribute |= EFI_MEMORY_ATT_WB;
+}
+
+res = raw_copy_to_guest_flush_dcache(tbl_virt, base_ptr, size);
+if ( res != 0 )
+panic("Unable to copy the stao to dom0 memory (left = %lu bytes)", 
res);
+size += get_acpi_size();
+set_acpi_size(size);
+
+xfree(base_ptr);
+return res;
+}
+
 static int create_xen_acpi_tables(struct kernel_info *kinfo, struct domain *d,
   struct membank tbl_add[])
 {
@@ -1375,6 +1480,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo, struct memb
 rsdp_tbl->xsdt_physical_address = tbl_add[TBL_XSDT].start;
 acpi_os_unmap_memory(rsdp_tbl, si

[Xen-devel] [PATCH v2 30/41] arm : acpi add placeholder for acpi load address

2015-05-17 Thread Parth Dixit
EFI table, memory description table and some of acpi tables
will reside in DOM0 memory. Add placeholder for starting
address for loading in DOM0 and get/set acpi size helpers.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/acpi/lib.c| 12 
 xen/arch/arm/kernel.c  |  5 -
 xen/arch/arm/kernel.h  |  1 +
 xen/include/asm-arm/acpi.h |  4 
 4 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index fd9bfa4..9b9f059 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -1,6 +1,8 @@
 #include 
 #include 
 
+static int acpi_len = 0;
+
 void __iomem *
 acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
 {
@@ -17,3 +19,13 @@ inline bool_t acpi_psci_hvc_present(void)
 {
 return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
 }
+
+inline int get_acpi_size(void)
+{
+return acpi_len;
+}
+
+inline void set_acpi_size(int size)
+{
+acpi_len = size;
+}
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 209c3dd..af6 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "kernel.h"
 
@@ -74,7 +75,8 @@ static void place_modules(struct kernel_info *info,
 const struct bootmodule *mod = info->initrd_bootmodule;
 const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2));
 const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2));
-const paddr_t modsize = initrd_len + dtb_len;
+const paddr_t acpi_len = ROUNDUP(get_acpi_size(), MB(2));
+const paddr_t modsize = initrd_len + dtb_len + acpi_len;
 
 /* Convenient */
 const paddr_t rambase = info->mem.bank[0].start;
@@ -119,6 +121,7 @@ static void place_modules(struct kernel_info *info,
 
 info->dtb_paddr = modbase;
 info->initrd_paddr = info->dtb_paddr + dtb_len;
+info->acpi_paddr = info->initrd_paddr + initrd_len;
 }
 
 static paddr_t kernel_zimage_place(struct kernel_info *info)
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 0050dfb..f3a67ac 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -26,6 +26,7 @@ struct kernel_info {
 const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
 paddr_t dtb_paddr;
 paddr_t initrd_paddr;
+paddr_t acpi_paddr;
 
 /* loader to use for this kernel */
 void (*load)(struct kernel_info *info);
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 2df9ae0..994c41e 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -37,11 +37,15 @@ bool_t acpi_psci_present(void);
 bool_t acpi_psci_hvc_present(void);
 void __init acpi_init_cpus(void);
 void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[]);
+int get_acpi_size(void);
+void set_acpi_size(int size);
 #else
 static inline bool_t acpi_psci_present(void) { return false; }
 static inline bool_t acpi_psci_hvc_present(void) {return false; }
 static inline void acpi_init_cpus(void) { }
 static inline void acpi_preinit_xen_time(unsigned int generic_timer_irq[]){ }
+static inline int get_acpi_size(void){return 0;}
+static inline void set_acpi_size(int size){}
 #endif /* CONFIG_ACPI */
 
 /* Basic configuration for ACPI */
-- 
1.9.1


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


[Xen-devel] [PATCH v2 29/41] arm : acpi read acpi memory info from uefi

2015-05-17 Thread Parth Dixit
ACPI memory is seperate from conventional memory and should
be marked as reserved while passing to DOM0. Create a new meminfo
structure to store all the acpi tables listed in uefi.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c |  2 ++
 xen/arch/arm/efi/efi-boot.h | 20 +---
 xen/include/asm-arm/setup.h |  1 +
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 865b81a..9d98f64 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,6 +42,8 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
+struct meminfo __initdata acpi_mem;
+
 //#define DEBUG_DT
 
 #ifdef DEBUG_DT
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index b02cc02..d21cba5 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -127,14 +127,16 @@ static EFI_STATUS __init 
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
 {
 int Index;
 int i = 0;
+int j = 0;
 EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
 
 for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
 {
-if ( desc_ptr->Type == EfiConventionalMemory
- || desc_ptr->Type == EfiBootServicesCode
- || desc_ptr->Type == EfiBootServicesData )
+switch( desc_ptr->Type )
 {
+case EfiConventionalMemory:
+case EfiBootServicesCode:
+case EfiBootServicesData:
 if ( i >= NR_MEM_BANKS )
 {
 PrintStr(L"Warning: All " __stringify(NR_MEM_BANKS)
@@ -144,11 +146,23 @@ static EFI_STATUS __init 
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
 bootinfo.mem.bank[i].start = desc_ptr->PhysicalStart;
 bootinfo.mem.bank[i].size = desc_ptr->NumberOfPages * 
EFI_PAGE_SIZE;
 ++i;
+break;
+case EfiACPIReclaimMemory:
+if ( j >= NR_MEM_BANKS )
+{
+PrintStr(L"Warning: All " __stringify(NR_MEM_BANKS)
+  " acpi meminfo mem banks exhausted.\r\n");
+break;
+}
+acpi_mem.bank[j].start = desc_ptr->PhysicalStart;
+acpi_mem.bank[j].size  = desc_ptr->NumberOfPages * EFI_PAGE_SIZE;
+++j;
 }
 desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
 }
 
 bootinfo.mem.nr_banks = i;
+acpi_mem.nr_banks = j;
 return EFI_SUCCESS;
 }
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index ba5a67d..1865b72 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -46,6 +46,7 @@ struct bootinfo {
 };
 
 extern struct bootinfo bootinfo;
+extern struct meminfo acpi_mem;
 
 void arch_init_memory(void);
 
-- 
1.9.1


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


[Xen-devel] [PATCH v2 34/41] arm : acpi create and map acpi tables

2015-05-17 Thread Parth Dixit
XSDT table cannot be passed as is to DOM0 because xen creates additional
tables which have to be added to XSDT table entry.
Copy existing XSDT and modify table to add new entries.
Create status override table,xen environment table.
Copy the tables to DOM0 memory.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 108 
 1 file changed, 108 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 90bdd01..36b072b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1225,16 +1226,123 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 #ifdef CONFIG_ACPI
+
+static int create_xen_acpi_tables(struct kernel_info *kinfo, struct domain *d,
+  struct membank tbl_add[])
+{
+unsigned long res;
+int offset=0;
+u64 size;
+u8 checksum;
+u64 *table_entry;
+u64 addr;
+u8 *base_ptr;
+struct acpi_table_xenv *xenv=NULL;
+struct acpi_table_stao *stao=NULL;
+struct acpi_table_header *table;
+void * __user tbl_virt = (void * __user)(register_t)kinfo->acpi_paddr;
+
+set_acpi_size(0);
+addr = tbl_add[TBL_XSDT].start;
+size = tbl_add[TBL_XSDT].size
+   - ( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
+
+table = acpi_os_map_memory(addr, size);
+size =   tbl_add[TBL_XSDT].size
+  +  tbl_add[TBL_XENV].size
+  +  tbl_add[TBL_STAO].size;
+
+base_ptr = xzalloc_bytes(size);
+if( base_ptr == NULL)
+return -ENOMEM;
+
+res = vgic_allocate_ppi(d);
+if ( res < 0 )
+panic("Unable to allocate a PPI for the event channel interrupt\n");
+
+d->arch.evtchn_irq = res;
+
+printk("Allocating PPI %u for event channel interrupt\n",
+   d->arch.evtchn_irq);
+
+   /* add xen env table */
+tbl_add[TBL_XENV].start =(u64)(base_ptr);
+xenv = (struct acpi_table_xenv *)(tbl_add[TBL_XENV].start);
+ACPI_MEMCPY((void *)xenv, table, sizeof(struct acpi_table_header));
+ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
+xenv->header.length = tbl_add[TBL_XENV].size;
+ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
+xenv->header.revision = 1;
+xenv->gnt_start = 0x001000;
+xenv->gnt_size = 0x2;
+xenv->evt_intr = d->arch.evtchn_irq;
+xenv->evt_intr_flag = ( 0xff & EVT_CHN_INTR_TRIG );
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), 
tbl_add[TBL_XENV].size);
+xenv->header.checksum = xenv->header.checksum - checksum;
+tbl_add[TBL_XENV].start = (u64)(tbl_virt);
+offset += tbl_add[TBL_XENV].size;
+
+/* add stao table */
+tbl_add[TBL_STAO].start =(u64)(base_ptr+offset);
+stao = (struct acpi_table_stao *)(tbl_add[TBL_STAO].start);
+ACPI_MEMCPY((void *)stao, table, sizeof(struct acpi_table_header));
+ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);
+stao->header.length = tbl_add[TBL_STAO].size;
+stao->uart = 1;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), 
tbl_add[TBL_STAO].size);
+stao->header.checksum = stao->header.checksum - checksum;
+tbl_add[TBL_STAO].start =(u64) (tbl_virt+offset);
+offset += tbl_add[TBL_STAO].size;
+
+/* fix xsdt table */
+ACPI_MEMCPY(base_ptr+offset, table,table->length);
+acpi_os_unmap_memory(table, table->length);
+
+table = (struct acpi_table_header *)(base_ptr+offset);
+table->length = tbl_add[TBL_XSDT].size;
+table_entry = ACPI_CAST_PTR(u64,
+(base_ptr+offset + sizeof(struct 
acpi_table_header) ) );
+table_entry +=
+( ( (table->length - sizeof(struct acpi_table_header) ) /
+sizeof(acpi_native_uint) ) );
+
+table_entry--;
+*table_entry = tbl_add[TBL_XENV].start ;
+
+table_entry--;
+*table_entry = tbl_add[TBL_STAO].start;
+
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
+table->checksum =  table->checksum - checksum;
+tbl_add[TBL_XSDT].start =(u64)(tbl_virt+offset);
+
+res = raw_copy_to_guest_flush_dcache(tbl_virt, base_ptr, size);
+if ( res != 0 )
+panic("Unable to copy the stao to dom0 memory (left = %lu bytes)", 
res);
+set_acpi_size(size);
+
+xfree(base_ptr);
+
+return 0;
+}
+
 static int prepare_acpi(struct domain *d, struct kernel_info *kinfo, struct 
membank tbl_add[])
 {
 unsigned long res;
 u64 addr, size;
 int i = 0;
+struct acpi_table_rsdp *rsdp_tbl;
 
+create_xen_acpi_tables(kinfo, d, tbl_add);
 addr = acpi_os_get_root_pointer();
 if( !addr )
 return -ENODEV;
 
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp) );
+rsdp_tbl->xsdt_physical_a

[Xen-devel] [PATCH v2 33/41] arm : acpi prepare acpi tables for dom0

2015-05-17 Thread Parth Dixit
Map acpi tables described in uefi table to DOM0 address space

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 59 -
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f2ca525..90bdd01 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1225,6 +1225,50 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 #ifdef CONFIG_ACPI
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo, struct 
membank tbl_add[])
+{
+unsigned long res;
+u64 addr, size;
+int i = 0;
+
+addr = acpi_os_get_root_pointer();
+if( !addr )
+return -ENODEV;
+
+size = sizeof(struct acpi_table_rsdp);
+
+res = map_regions(d,
+  paddr_to_pfn(addr & PAGE_MASK),
+  DIV_ROUND_UP(size, PAGE_SIZE),
+  paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
+{
+addr = acpi_gbl_root_table_list.tables[i].address;
+size = acpi_gbl_root_table_list.tables[i].length;
+res = map_regions(d,
+  paddr_to_pfn(addr & PAGE_MASK),
+  DIV_ROUND_UP(size, PAGE_SIZE),
+  paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+}
+
+return 0;
+}
+
 static int estimate_acpi_size(struct domain *d,struct kernel_info *kinfo, 
struct membank tbl_add[])
 {
 int size = 0;
@@ -1429,6 +1473,10 @@ static int create_acpi_dtb(struct domain *d, struct 
kernel_info *kinfo, struct m
 {
 return -EINVAL;
 }
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo, struct 
membank tbl_add[])
+{
+return -EINVAL;
+}
 #endif
 static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 {
@@ -1647,10 +1695,19 @@ int construct_dom0(struct domain *d)
  * as the initrd & fdt in RAM, so call it first.
  */
 kernel_load(&kinfo);
+
+if ( !acpi_disabled )
+{
+rc = prepare_acpi(d, &kinfo, tbl_add);
+if ( rc < 0 )
+return rc;
+}
+
 /* initrd_load will fix up the fdt, so call it before dtb_load */
 initrd_load(&kinfo);
 /* Allocate the event channel IRQ and fix up the device tree */
-evtchn_fixup(d, &kinfo);
+if( acpi_disabled )
+evtchn_fixup(d, &kinfo);
 dtb_load(&kinfo);
 
 /* Now that we are done restore the original p2m and current. */
-- 
1.9.1


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


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

2015-05-17 Thread Parth Dixit
RSDP and memory map will be passed via
efi table. DTB wil contain the address of
EFI table, starting address of memory
map desctiption table and description
size.

Address of EFI table and memory map description
is not available at the time creation of DT.
Create stub entries which will be fixed later

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 50 +
 xen/include/xen/efi.h   | 11 +-
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e688a78..865b81a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1219,6 +1220,51 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 #ifdef CONFIG_ACPI
+/*
+ * Create place holder for efi values.
+ * Actual values will be replaced later
+ */
+static int make_efi_nodes(struct domain *d,void *fdt,
+   const struct kernel_info *kinfo)
+{
+u64 fdt_val64;
+u32 fdt_val32;
+int desc_size = sizeof(struct efi_memory_desc);
+int desc_ver = EFI_MEM_DESC_V1;
+int res;
+u64 addr = 0;
+
+fdt_val64 = cpu_to_fdt64((u64)(uintptr_t)addr);
+res = fdt_property(fdt, "linux,uefi-system-table",
+   &fdt_val64, sizeof(fdt_val64));
+if ( res )
+return res;
+
+fdt_val64 = cpu_to_fdt64((u64)(uintptr_t)addr);
+res = fdt_property(fdt, "linux,uefi-mmap-start",
+   &fdt_val64,  sizeof(fdt_val64));
+if ( res )
+return res;
+
+fdt_val32 = cpu_to_fdt32(desc_size);
+res = fdt_property(fdt, "linux,uefi-mmap-size",
+   &fdt_val32,  sizeof(fdt_val32));
+if ( res )
+return res;
+
+fdt_val32 = cpu_to_fdt32(desc_size);
+res = fdt_property(fdt, "linux,uefi-mmap-desc-size",
+ &fdt_val32, sizeof(fdt_val32));
+ if ( res )
+return res;
+
+fdt_val32 = cpu_to_fdt32(desc_ver);
+res = fdt_property(fdt, "linux,uefi-mmap-desc-ver",
+ &fdt_val32, sizeof(fdt_val32));
+
+return res;
+}
+
 static int make_chosen_node(struct domain *d, const struct kernel_info *kinfo)
 {
 int res = 0;
@@ -1255,6 +1301,10 @@ static int make_chosen_node(struct domain *d, const 
struct kernel_info *kinfo)
 return res;
 }
 
+res = make_efi_nodes(d, fdt, kinfo);
+if ( res )
+return res;
+
 res = fdt_end_node(fdt);
 
 return res;
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 48de8e0..26b2f45 100644
--- 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;
-- 
1.9.1


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


[Xen-devel] [PATCH v2 25/41] arm : acpi add status override table

2015-05-17 Thread Parth Dixit
Status override table is used to hide devices from DOM0
that are used by xen

Signed-off-by: Parth Dixit 
---
 xen/include/acpi/actbl2.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 25be429..9c8d807 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -79,6 +79,7 @@
 #define ACPI_SIG_WDAT   "WDAT" /* Watchdog Action Table */
 #define ACPI_SIG_WDDT   "WDDT" /* Watchdog Timer Description Table */
 #define ACPI_SIG_WDRT   "WDRT" /* Watchdog Resource Table */
+#define ACPI_SIG_STAO   "STAO" /* Status Override Table */
 
 #ifdef ACPI_UNDEFINED_TABLES
 /*
@@ -894,6 +895,19 @@ struct acpi_table_uefi {
 };
 
 
/***
+  *
+  * STAO - Status Override Table
+  *Version 0.3
+  *
+ 
**/
+
+struct acpi_table_stao {
+struct acpi_table_header header;   /* Common ACPI table header */
+u8 uart;/* Indicates presence of SPCR table */
+u8 devpath[1];/* Full namepath of uart device in ACPI namespace */
+};
+
+/***
  *
  * WAET - Windows ACPI Emulated devices Table
  *Version 1
-- 
1.9.1


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


[Xen-devel] [PATCH v2 27/41] arm : add helper functions to map memory regions

2015-05-17 Thread Parth Dixit
creates a helper function for mapping with cached attributes

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/p2m.c| 26 ++
 xen/include/asm-arm/p2m.h | 10 ++
 2 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 903fa3f..fcb8116 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1140,6 +1140,32 @@ int p2m_populate_ram(struct domain *d,
  d->arch.p2m.default_access);
 }
 
+int map_regions(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)
+{
+return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_mmio_direct,
+ d->arch.p2m.default_access);
+}
+
+int unmap_regions(struct domain *d,
+   unsigned long start_gfn,
+   unsigned long nr,
+   unsigned long mfn)
+{
+return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_invalid,
+ d->arch.p2m.default_access);
+}
+
 int map_mmio_regions(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 63748ef..5436ae7 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -152,6 +152,16 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, 
xen_pfn_t end_mfn);
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 
+int map_regions(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr_mfns,
+unsigned long mfn);
+
+int unmap_regions(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr_mfns,
+unsigned long mfn);
+
 int guest_physmap_add_entry(struct domain *d,
 unsigned long gfn,
 unsigned long mfn,
-- 
1.9.1


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


[Xen-devel] [PATCH v2 35/41] arm : acpi add helper function to calculate crc32

2015-05-17 Thread Parth Dixit
Add helper functions for calculating crc32.
This is required for computing crc of efi table.
These functions are copied from here
http://mirrors.neusoft.edu.cn/rpi-kernel/lib/xz/xz_crc32.c
Original author's are  Lasse Collin and Igor Pavlov.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 36b072b..0ad70c1 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1227,6 +1227,39 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 }
 #ifdef CONFIG_ACPI
 
+static uint32_t xz_crc32_table[256];
+
+static void xz_crc32_init(void)
+{
+   const uint32_t poly = 0xEDB88320;
+
+   uint32_t i;
+   uint32_t j;
+   uint32_t r;
+
+   for (i = 0; i < 256; ++i) {
+   r = i;
+   for (j = 0; j < 8; ++j)
+   r = (r >> 1) ^ (poly & ~((r & 1) - 1));
+
+   xz_crc32_table[i] = r;
+   }
+
+   return;
+}
+
+static uint32_t xz_crc32(uint8_t *buf, size_t size, uint32_t crc)
+{
+   crc = ~crc;
+
+   while (size != 0) {
+   crc = xz_crc32_table[*buf++ ^ (crc & 0xFF)] ^ (crc >> 8);
+   --size;
+   }
+
+   return ~crc;
+}
+
 static int create_xen_acpi_tables(struct kernel_info *kinfo, struct domain *d,
   struct membank tbl_add[])
 {
-- 
1.9.1


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


[Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table

2015-05-17 Thread Parth Dixit
Xen environment table is ACPI table that is used to pass grant table
and event channel interrupt information to dom0.

Signed-off-by: Parth Dixit 
---
 xen/include/acpi/actbl2.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 9c8d807..fc3ec2d 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -80,6 +80,7 @@
 #define ACPI_SIG_WDDT   "WDDT" /* Watchdog Timer Description Table */
 #define ACPI_SIG_WDRT   "WDRT" /* Watchdog Resource Table */
 #define ACPI_SIG_STAO   "STAO" /* Status Override Table */
+#define ACPI_SIG_XENV   "XENV" /* Xen Environment Table */
 
 #ifdef ACPI_UNDEFINED_TABLES
 /*
@@ -909,6 +910,25 @@ struct acpi_table_stao {
 
 
/***
  *
+ * XENV - Xen Environment Table
+ *Version 0.2
+ *
+ 
**/
+
+struct acpi_table_xenv {
+struct acpi_table_header header;/* Common ACPI table header */
+u64 gnt_start;/* Starting address of Xen grant table region */
+u64 gnt_size; /* Size of Xen grant table region */
+u32 evt_intr;/* Xen event channel interrupt */
+u8  evt_intr_flag;/* Flags for event channel interrupt */
+};
+
+/* Event Channel Interrupt Flags */
+#define EVT_CHN_INTR_MODE (1 << 0)
+#define EVT_CHN_INTR_TRIG (1 << 1)
+
+/***
+ *
  * WAET - Windows ACPI Emulated devices Table
  *Version 1
  *
-- 
1.9.1


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


[Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions

2015-05-17 Thread Parth Dixit
In ACPI mmio regions are described in DSDT which requires
AML interpreter. Defer the mapping of mmio until DSDT is parsed in
DOM0 and map mmio's dynamically at the time of request.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/traps.c | 51 ++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 47d6cef..6b8d247 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -46,6 +47,7 @@
 #include "vtimer.h"
 #include 
 #include 
+#include 
 
 /* The base of the stack must always be double-word aligned, which means
  * that both the kernel half of struct cpu_user_regs (which is pushed in
@@ -2336,6 +2338,47 @@ bad_insn_abort:
 inject_iabt_exception(regs, gva, hsr.len);
 }
 
+#ifdef CONFIG_ACPI
+static int map_mmio_dsdt(struct cpu_user_regs *regs,
+ mmio_info_t *info)
+{
+int res;
+u64 addr,size;
+struct domain* d = current->domain;
+
+if ( !is_hardware_domain(d) )
+return 0;
+
+addr = info->gpa;
+size = PAGE_SIZE;
+
+res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
+  paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to dom%d access to"
+   " 0x%"PRIx64" - 0x%"PRIx64"\n",
+   d->domain_id,
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+return 0;
+}
+res = map_mmio_regions(d,
+   paddr_to_pfn(addr & PAGE_MASK),
+   DIV_ROUND_UP(size, PAGE_SIZE),
+   paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+   " - 0x%"PRIx64" in domain %d\n",
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1,
+   d->domain_id);
+return 0;
+}
+
+return 1;
+}
+#endif
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
  const union hsr hsr)
 {
@@ -2411,7 +2454,13 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 advance_pc(regs, hsr);
 return;
 }
-
+#ifdef CONFIG_ACPI
+if( !acpi_disabled )
+{
+if( map_mmio_dsdt(regs, &info) )
+return;
+}
+#endif
 bad_data_abort:
 inject_dabt_exception(regs, info.gva, hsr.len);
 }
-- 
1.9.1


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


[Xen-devel] [PATCH v2 31/41] arm : acpi estimate memory required for acpi/efi tables

2015-05-17 Thread Parth Dixit
Estimate the memory required for loading acpi/efi tablee
in DOM0. Initialize the size of acpi/efi tables.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 54 -
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9d98f64..f2ca525 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -69,6 +69,9 @@ struct meminfo __initdata acpi_mem;
 #ifdef CONFIG_ACPI
 /* Reserve DOM0 FDT size in ACPI case only */
 #define DOM0_FDT_MIN_SIZE 4096
+#define NR_NEW_XEN_TABLES 2
+/* Constant to indicate "Xen" in unicode u16 format */
+static const u16 XEN_EFI_FW_VENDOR[] ={0x0058,0x0065,0x006E,0x};
 #endif
 
 struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
@@ -1222,6 +1225,51 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 #ifdef CONFIG_ACPI
+static int estimate_acpi_size(struct domain *d,struct kernel_info *kinfo, 
struct membank tbl_add[])
+{
+int size = 0;
+u64 addr;
+struct acpi_table_header *table;
+struct acpi_table_rsdp *rsdp_tbl;
+
+set_acpi_size(size);
+tbl_add[TBL_EFIT].size = sizeof(struct efi_system_table)
++ sizeof(struct efi_config_table)
++ sizeof(XEN_EFI_FW_VENDOR);
+
+tbl_add[TBL_MMAP].size = sizeof(struct efi_memory_desc)
+*(kinfo->mem.nr_banks + acpi_mem.nr_banks + TBL_MMAX);
+tbl_add[TBL_XENV].size = sizeof(struct acpi_table_xenv);
+tbl_add[TBL_STAO].size = sizeof(struct acpi_table_stao);
+
+addr = acpi_os_get_root_pointer();
+if( !addr )
+return -ENODEV;
+
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
+if( !rsdp_tbl )
+return -ENOMEM;
+
+table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
+   sizeof(struct acpi_table_header));
+if ( !table )
+return -ENOMEM;
+
+tbl_add[TBL_XSDT].size = table->length
++( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
+tbl_add[TBL_XSDT].start = rsdp_tbl->xsdt_physical_address;
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
+size = tbl_add[TBL_EFIT].size
++ tbl_add[TBL_MMAP].size
++ tbl_add[TBL_XENV].size
++ tbl_add[TBL_STAO].size
++ tbl_add[TBL_XSDT].size;
+
+set_acpi_size(size);
+return 0;
+}
+
 /*
  * Create place holder for efi values.
  * Actual values will be replaced later
@@ -1365,7 +1413,11 @@ static int create_acpi_dtb(struct domain *d, struct 
kernel_info *kinfo, struct m
 if ( ret < 0 )
 goto err;
 
-return 0;
+ret = estimate_acpi_size(d, kinfo, tbl_add);
+if ( ret < 0 )
+goto err;
+
+   return 0;
 
   err:
 printk("Device tree generation failed (%d).\n", ret);
-- 
1.9.1


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


[Xen-devel] [PATCH v2 23/41] arm : acpi create chosen node for DOM0

2015-05-17 Thread Parth Dixit
Create a chosen node for DOM0 with
 - bootargs
 - initrd

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 46 +
 1 file changed, 46 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c830702..e688a78 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1219,6 +1219,47 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 #ifdef CONFIG_ACPI
+static int make_chosen_node(struct domain *d, const struct kernel_info *kinfo)
+{
+int res = 0;
+const char *bootargs = NULL;
+const struct bootmodule *mod = kinfo->kernel_bootmodule;
+void *fdt = kinfo->fdt;
+
+DPRINT("Create bootargs chosen node\n");
+
+if ( mod && mod->cmdline[0] )
+ bootargs = &mod->cmdline[0];
+
+res = fdt_begin_node(fdt, "chosen");
+if ( res )
+return res;
+
+res = fdt_property(fdt, "bootargs", bootargs, (strlen(bootargs)+1));
+if ( res )
+   return res;
+
+/*
+ * If the bootloader provides an initrd, we must create a placeholder
+ * for the initrd properties. The values will be replaced later.
+ */
+if ( mod && mod->size )
+{
+u64 a = 0;
+res = fdt_property(kinfo->fdt, "linux,initrd-start", &a, sizeof(a));
+if ( res )
+return res;
+
+res = fdt_property(kinfo->fdt, "linux,initrd-end", &a, sizeof(a));
+if ( res )
+return res;
+}
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
 /*
  * Prepare a minimal DTB for DOM0 which contains
  * bootargs, initrd, memory information,
@@ -1259,6 +1300,11 @@ static int create_acpi_dtb(struct domain *d, struct 
kernel_info *kinfo, struct m
 if ( ret )
 return ret;
 
+/* Create a chosen node for DOM0 */
+ret = make_chosen_node(d, kinfo);
+if ( ret )
+goto err;
+
 ret = fdt_end_node(kinfo->fdt);
 if ( ret < 0 )
 goto err;
-- 
1.9.1


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


[Xen-devel] [PATCH v2 28/41] arm : acpi add efi structures to common efi header

2015-05-17 Thread Parth Dixit
add efi table and memory descriptor structures
to common efi header file and pass efi system table address
retrieved from uefi.This is required for
creating efi table and passing memory information
to DOM0

Signed-off-by: Parth Dixit 
---
 xen/common/efi/boot.c |  2 ++
 xen/include/xen/efi.h | 54 +++
 2 files changed, 56 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index f5e179b..906e040 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1009,6 +1009,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
   efi.smbios3 = (long)efi_ct[i].VendorTable;
 }
 
+efi.est = (long)SystemTable;
+
 #ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
 dmi_efi_get_table(efi.smbios != EFI_INVALID_TABLE_ADDR
   ? (void *)(long)efi.smbios : NULL,
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 26b2f45..9fdc72b 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -16,10 +16,46 @@ struct efi {
 unsigned long acpi20;   /* ACPI table (ACPI 2.0) */
 unsigned long smbios;   /* SM BIOS table */
 unsigned long smbios3;  /* SMBIOS v3 table */
+unsigned long est;  /* EFI system table */
 };
 
 extern struct efi efi;
 
+/*
+ * Generic EFI table header
+ */
+struct  efi_table_hdr {
+u64 signature;
+u32 revision;
+u32 headersize;
+u32 crc32;
+u32 reserved;
+};
+
+struct efi_guid{
+u8 b[16];
+};
+
+#define EFI_GUID(a,b,c,d0,d1,d2,d3,d4,d5,d6,d7) \
+((struct efi_guid)   \
+{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
+(b) & 0xff, ((b) >> 8) & 0xff,  \
+(c) & 0xff, ((c) >> 8) & 0xff,  \
+(d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
+
+#define ACPI_20_TBL_GUID  \
+EFI_GUID(  0x8868e871, 0xe4f1, 0x11d3, 0xbc, 0x22, 0x0, 0x80, 0xc7, 0x3c, 
0x88, 0x81 )
+
+#define EFI_CONVENTIONAL_MEMORY 7
+#define EFI_ACPI_RECLAIM_MEMORY 9
+
+#define EFI_MEMORY_ATT_WB  ((u64)0x0008ULL)/* 
write-back */
+
+struct efi_config_table {
+struct efi_guid guid;
+u64 table;
+};
+
 struct efi_memory_desc {
 u32 type;
 u32 pad;
@@ -29,6 +65,24 @@ struct efi_memory_desc {
 u64 attribute;
 };
 
+struct efi_system_table {
+struct efi_table_hdr hdr;
+u64 fw_vendor; /* physical addr of CHAR16 vendor string */
+u32 fw_revision;
+u32 __pad1;
+u64 con_in_handle;
+u64 con_in;
+u64 con_out_handle;
+u64 con_out;
+u64 stderr_handle;
+u64 stderr;
+u64 runtime;
+u64 boottime;
+u32 nr_tables;
+u32 __pad2;
+u64 tables;
+};
+
 #ifndef __ASSEMBLY__
 
 union xenpf_efi_info;
-- 
1.9.1


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


[Xen-devel] [PATCH v2 19/41] arm : acpi Add GIC specific ACPI boot support

2015-05-17 Thread Parth Dixit
ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
It needs to parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv2.

Modify MADT table to clear GICH and GICV which are not needed
in Dom0.

NOTE: This commit allow to initialize GICv2 only.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/gic-v2.c   | 132 +-
 xen/arch/arm/gic.c  |  18 +-
 xen/drivers/char/arm-uart.c | 136 
 3 files changed, 284 insertions(+), 2 deletions(-)
 create mode 100644 xen/drivers/char/arm-uart.c

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 7276951..fcdcd19 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -35,6 +37,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * LR register definitions are GIC v2 specific.
@@ -692,9 +695,122 @@ static int __init dt_gicv2_init(void)
 return 0;
 }
 
+#ifdef CONFIG_ACPI
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+
+if (BAD_MADT_ENTRY(processor, end))
+return -EINVAL;
+
+/* Read from APIC table and fill up the GIC variables */
+
+gicv2.cbase = processor->base_address;
+gicv2.hbase = processor->gich_base_address;
+gicv2.vbase = processor->gicv_base_address;
+gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
+if( processor->flags & ACPI_MADT_ENABLED )
+{
+if( processor->flags & ACPI_MADT_VGIC )
+set_irq_type(gicv2_info.maintenance_irq, 
ACPI_IRQ_TYPE_EDGE_BOTH);
+else
+set_irq_type(gicv2_info.maintenance_irq, 
ACPI_IRQ_TYPE_LEVEL_MASK);
+}
+
+processor->gich_base_address = 0;
+processor->gicv_base_address = 0;
+processor->vgic_maintenance_interrupt = 0;
+clean_dcache_va_range(processor, sizeof(struct 
acpi_madt_generic_interrupt));
+
+return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_distributor *dist;
+
+dist = (struct acpi_madt_generic_distributor *)header;
+
+if (BAD_MADT_ENTRY(dist, end))
+return -EINVAL;
+
+gicv2.dbase = dist->base_address;
+
+return 0;
+}
+
+static int __init acpi_gicv2_init(void)
+{
+acpi_status status;
+struct acpi_table_header *table;
+u8 checksum;
+int res;
+
+status = acpi_get_table(ACPI_SIG_MADT, 0, &table);
+
+if ( ACPI_FAILURE(status) )
+{
+  const char *msg = acpi_format_exception(status);
+  printk("\nFailed to get MADT table, %s\n", msg);
+  return 1;
+}
+
+/* Collect CPU base addresses */
+res = acpi_parse_entries(ACPI_SIG_MADT,
+sizeof(struct acpi_table_madt),
+gic_acpi_parse_madt_cpu, table,
+ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+0);
+if ( res < 0 )
+{
+printk("Error during GICC entries parsing\n");
+printk("\nFailed to initialize GIC IRQ controller\n");
+return -EINVAL;
+}
+
+/*
+ * Find distributor base address. We expect one distributor entry since
+ * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
+ */
+res = acpi_parse_entries(ACPI_SIG_MADT,
+sizeof(struct acpi_table_madt),
+gic_acpi_parse_madt_distributor, table,
+ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
+0);
+
+if ( res < 0 )
+{
+printk("Error during GICD entries parsing\n");
+printk("\nFailed to initialize GIC IRQ controller\n");
+return -EINVAL;
+}
+
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
+table->checksum -= checksum;
+clean_dcache_va_range(table, sizeof(struct acpi_table_header));
+
+return 0;
+}
+#else
+static int __init acpi_gicv2_init(void)
+{
+/* Should never reach here */
+return -EINVAL;
+}
+#endif
+
 static int gicv2_init(void)
 {
- dt_gicv2_init();
+if( acpi_disabled )
+dt_gicv2_init();
+else
+acpi_gi

[Xen-devel] [PATCH v2 20/41] arm : create generic uart initialization function

2015-05-17 Thread Parth Dixit
Rename dt-uart.c to arm-uart.c and create new generic uart init function.
move dt_uart_init to uart_init. Refactor pl011 driver to dt and common
initialization parts. This will be useful later when acpi specific
uart initialization function is introduced.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/setup.c   |   2 +-
 xen/drivers/char/Makefile  |   2 +-
 xen/drivers/char/dt-uart.c | 107 -
 xen/drivers/char/pl011.c   |  47 
 xen/include/xen/serial.h   |   3 +-
 5 files changed, 33 insertions(+), 128 deletions(-)
 delete mode 100644 xen/drivers/char/dt-uart.c

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5711077..1b2d74c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -771,7 +771,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 gic_preinit();
 
-dt_uart_init();
+uart_init();
 console_init_preirq();
 console_init_ring();
 
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 47fc3f9..a8f65c1 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -6,5 +6,5 @@ obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
 obj-$(HAS_SCIF) += scif-uart.o
 obj-$(HAS_EHCI) += ehci-dbgp.o
-obj-$(CONFIG_ARM) += dt-uart.o
+obj-$(CONFIG_ARM) += arm-uart.o
 obj-y += serial.o
diff --git a/xen/drivers/char/dt-uart.c b/xen/drivers/char/dt-uart.c
deleted file mode 100644
index d599322..000
--- a/xen/drivers/char/dt-uart.c
+++ /dev/null
@@ -1,107 +0,0 @@
-/*
- * xen/drivers/char/dt-uart.c
- *
- * Generic uart retrieved via the device tree
- *
- * Julien Grall 
- * Copyright (c) 2013 Linaro Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*
- * Configure UART port with a string:
- * path:options
- *
- * @path: full path used in the device tree for the UART. If the path
- * doesn't start with '/', we assuming that it's an alias.
- * @options: UART speficic options (see in each UART driver)
- */
-static char __initdata opt_dtuart[256] = "";
-string_param("dtuart", opt_dtuart);
-
-void __init dt_uart_init(void)
-{
-struct dt_device_node *dev;
-int ret;
-const char *devpath = opt_dtuart;
-char *options;
-
-if ( !console_has("dtuart") )
-return; /* Not for us */
-
-if ( !strcmp(opt_dtuart, "") )
-{
-const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
-
-if ( chosen )
-{
-const char *stdout;
-
-ret = dt_property_read_string(chosen, "stdout-path", &stdout);
-if ( ret >= 0 )
-{
-printk("Taking dtuart configuration from 
/chosen/stdout-path\n");
-if ( strlcpy(opt_dtuart, stdout, sizeof(opt_dtuart))
- >= sizeof(opt_dtuart) )
-printk("WARNING: /chosen/stdout-path too long, 
truncated\n");
-}
-else if ( ret != -EINVAL /* Not present */ )
-printk("Failed to read /chosen/stdout-path (%d)\n", ret);
-}
-}
-
-if ( !strcmp(opt_dtuart, "") )
-{
-printk("No dtuart path configured\n");
-return;
-}
-
-options = strchr(opt_dtuart, ':');
-if ( options != NULL )
-*(options++) = '\0';
-else
-options = "";
-
-printk("Looking for dtuart at \"%s\", options \"%s\"\n", devpath, options);
-if ( *devpath == '/' )
-dev = dt_find_node_by_path(devpath);
-else
-dev = dt_find_node_by_alias(devpath);
-
-if ( !dev )
-{
-printk("Unable to find device \"%s\"\n", devpath);
-return;
-}
-
-ret = device_init(dev, DEVICE_SERIAL, options);
-
-if ( ret )
-printk("Unable to initialize dtuart: %d\n", ret);
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 67e6df5..f0c3daf 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -225,9 +225,32 @@ static struct uart_driver __read_mostly pl011_driver = {
 .stop_tx  = pl011_tx_stop,
 

[Xen-devel] [PATCH v2 22/41] arm : acpi create min DT stub for DOM0

2015-05-17 Thread Parth Dixit
Create a DT for DOM0 for ACPI-case only.
DT contains minmal required informations such as
DOM0 bootargs, initrd, efi description table
and address of uefi memory table.
Add placeholder for tables to be marked as
reserved in efi table. This is requird for
DT function's signature.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 75 -
 xen/include/asm-arm/acpi.h  | 10 ++
 2 files changed, 84 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1e545fe..c830702 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -61,6 +63,11 @@ custom_param("dom0_mem", parse_dom0_mem);
  */
 #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
 
+#ifdef CONFIG_ACPI
+/* Reserve DOM0 FDT size in ACPI case only */
+#define DOM0_FDT_MIN_SIZE 4096
+#endif
+
 struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 {
 if ( opt_dom0_max_vcpus == 0 )
@@ -1211,7 +1218,68 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 
 return res;
 }
+#ifdef CONFIG_ACPI
+/*
+ * Prepare a minimal DTB for DOM0 which contains
+ * bootargs, initrd, memory information,
+ * EFI table.
+ */
+static int create_acpi_dtb(struct domain *d, struct kernel_info *kinfo, struct 
membank tbl_add[])
+{
+int new_size;
+int ret;
+
+DPRINT("Prepare a min DTB for DOM0\n");
+
+/* Allocate min size for DT */
+new_size = DOM0_FDT_MIN_SIZE;
+kinfo->fdt = xmalloc_bytes(DOM0_FDT_MIN_SIZE);
+
+if ( kinfo->fdt == NULL )
+return -ENOMEM;
+
+/* Create a new empty DT for DOM0 */
+ret = fdt_create(kinfo->fdt, new_size);
+if ( ret < 0 )
+goto err;
+
+ret = fdt_finish_reservemap(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+ret = fdt_begin_node(kinfo->fdt, "/");
+if ( ret < 0 )
+goto err;
+
+ret = fdt_property_cell(kinfo->fdt, "#address-cells", 2);
+if ( ret )
+return ret;
 
+ret = fdt_property_cell(kinfo->fdt, "#size-cells", 1);
+if ( ret )
+return ret;
+
+ret = fdt_end_node(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+ret = fdt_finish(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+return 0;
+
+  err:
+printk("Device tree generation failed (%d).\n", ret);
+xfree(kinfo->fdt);
+return -EINVAL;
+}
+#else
+static int create_acpi_dtb(struct domain *d, struct kernel_info *kinfo, struct 
membank tbl_add[])
+{
+return -EINVAL;
+}
+#endif
 static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 {
 const void *fdt;
@@ -1370,6 +1438,7 @@ int construct_dom0(struct domain *d)
 struct kernel_info kinfo = {};
 struct vcpu *saved_current;
 int rc, i, cpu;
+struct membank tbl_add[TBL_MMAX] = {};
 
 struct vcpu *v = d->vcpu[0];
 struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
@@ -1403,7 +1472,11 @@ int construct_dom0(struct domain *d)
 
 allocate_memory(d, &kinfo);
 
-rc = prepare_dtb(d, &kinfo);
+if (acpi_disabled)
+rc = prepare_dtb(d, &kinfo);
+else
+rc = create_acpi_dtb(d, &kinfo, tbl_add);
+
 if ( rc < 0 )
 return rc;
 
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 482cc5b..2df9ae0 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -50,6 +50,16 @@ static inline void disable_acpi(void)
 acpi_disabled = 1;
 }
 
+/* Tables marked as reserved in efi table */
+enum EFI_MEM_RES{
+TBL_STAO,
+TBL_XENV,
+TBL_XSDT,
+TBL_EFIT,
+TBL_MMAP,
+TBL_MMAX,
+};
+
 #define ACPI_GTDT_INTR_MASK ( ACPI_GTDT_INTERRUPT_MODE | 
ACPI_GTDT_INTERRUPT_POLARITY )
 
 /**
-- 
1.9.1


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


[Xen-devel] [PATCH v2 21/41] arm : acpi Initialize serial port from ACPI SPCR table

2015-05-17 Thread Parth Dixit
Parse ACPI SPCR (Serial Port Console Redirection table) table and
initialize the serial port pl011.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/drivers/char/pl011.c  | 49 +++
 xen/include/acpi/actbl2.h |  5 +
 2 files changed, 54 insertions(+)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index f0c3daf..bc34555 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -307,6 +308,54 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
 .init = dt_pl011_uart_init,
 DT_DEVICE_END
 
+#ifdef CONFIG_ACPI
+static int __init acpi_pl011_uart_init(const void *data)
+{
+struct pl011 *uart;
+acpi_status status;
+struct acpi_table_spcr *spcr=NULL;
+int res;
+
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **)&spcr);
+
+if ( ACPI_FAILURE(status) )
+{
+printk("\nFailed to get SPCR table \n");
+return 1;
+}
+
+uart = &pl011_com;
+
+if ( spcr->interrupt < 0 )
+{
+printk("pl011: Unable to retrieve the IRQ\n");
+return -EINVAL;
+}
+
+uart->irq = spcr->interrupt;
+/* trigger/polarity information is not available in spcr */
+set_irq_type(uart->irq, ACPI_IRQ_TYPE_EDGE_BOTH);
+
+res = pl011_uart_init(uart, spcr->serial_port.address, PAGE_SIZE);
+if ( res < 0 )
+{
+printk("pl011: Unable to initialize\n");
+return res;
+}
+
+/* Register with generic serial driver. */
+serial_register_uart(SERHND_UART, &pl011_driver, uart);
+
+return 0;
+}
+
+ACPI_DEVICE_START(apl011, "PL011 UART", DEVICE_SERIAL)
+.class_type = ACPI_SPCR_TYPE_PL011,
+.init = acpi_pl011_uart_init,
+ACPI_DEVICE_END
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 87bc6b3..25be429 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -815,6 +815,11 @@ struct acpi_table_spcr {
 
 #define ACPI_SPCR_DO_NOT_DISABLE(1)
 
+/* UART Interface type */
+#define ACPI_SPCR_TYPE_16550 0
+#define ACPI_SPCR_TYPE_16550_SUB 1
+#define ACPI_SPCR_TYPE_PL011 3
+
 
/***
  *
  * SPMI - Server Platform Management Interface table
-- 
1.9.1


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


[Xen-devel] [PATCH v2 17/41] arm : refactor gic into generic and dt specific parts

2015-05-17 Thread Parth Dixit
refactor gic related functions into dt and generic parts
this will be helpful when adding acpi support for gic

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/gic-v2.c | 13 ++---
 xen/arch/arm/gic.c|  7 ++-
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 80acc62..7276951 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -663,7 +663,7 @@ static hw_irq_controller gicv2_guest_irq_type = {
 .set_affinity = gicv2_irq_set_affinity,
 };
 
-static int __init gicv2_init(void)
+static int __init dt_gicv2_init(void)
 {
 int res;
 const struct dt_device_node *node = gicv2_info.node;
@@ -689,6 +689,13 @@ static int __init gicv2_init(void)
 panic("GICv2: Cannot find the maintenance IRQ");
 gicv2_info.maintenance_irq = res;
 
+return 0;
+}
+
+static int gicv2_init(void)
+{
+ dt_gicv2_init();
+
 /* TODO: Add check on distributor, cpu size */
 
 printk("GICv2 initialization:\n"
@@ -763,7 +770,7 @@ const static struct gic_hw_operations gicv2_ops = {
 };
 
 /* Set up the GIC */
-static int __init gicv2_preinit(struct dt_device_node *node, const void *data)
+static int __init dt_gicv2_preinit(struct dt_device_node *node, const void 
*data)
 {
 gicv2_info.hw_version = GIC_V2;
 gicv2_info.node = node;
@@ -781,7 +788,7 @@ static const struct dt_device_match gicv2_dt_match[] 
__initconst =
 
 DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
 .dt_match = gicv2_dt_match,
-.init = gicv2_preinit,
+.init = dt_gicv2_preinit,
 DT_DEVICE_END
 
 /*
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index f023e4f..701c306 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -231,7 +231,7 @@ int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
 /* Find the interrupt controller and set up the callback to translate
  * device tree IRQ.
  */
-void __init gic_preinit(void)
+void __init dt_gic_preinit(void)
 {
 int rc;
 struct dt_device_node *node;
@@ -261,6 +261,11 @@ void __init gic_preinit(void)
 dt_device_set_used_by(node, DOMID_XEN);
 }
 
+void __init gic_preinit(void)
+{
+dt_gic_preinit();
+}
+
 /* Set up the GIC */
 void __init gic_init(void)
 {
-- 
1.9.1


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


[Xen-devel] [PATCH v2 18/41] arm: Introduce a generic way to use a device from acpi

2015-05-17 Thread Parth Dixit
add generic way to use device from acpi similar to
the way it is supported in device tree.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/device.c| 19 +++
 xen/arch/arm/xen.lds.S   |  7 +++
 xen/include/asm-arm/device.h | 30 ++
 3 files changed, 56 insertions(+)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 0b53f6a..5494de0 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -22,6 +22,7 @@
 #include 
 
 extern const struct device_desc _sdevice[], _edevice[];
+extern const struct acpi_device_desc _asdevice[], _aedevice[];
 
 int __init device_init(struct dt_device_node *dev, enum device_class class,
const void *data)
@@ -50,6 +51,24 @@ int __init device_init(struct dt_device_node *dev, enum 
device_class class,
 return -EBADF;
 }
 
+int __init acpi_device_init(enum device_class class, const void *data, int 
class_type)
+{
+const struct acpi_device_desc *desc;
+
+for ( desc = _asdevice; desc != _aedevice; desc++ )
+{
+if ( ( desc->class != class ) && ( desc->class_type != class_type ) )
+continue;
+
+
+ASSERT(desc->init != NULL);
+
+return desc->init(data);
+}
+
+return -EBADF;
+}
+
 enum device_class device_get_class(const struct dt_device_node *dev)
 {
 const struct device_desc *desc;
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 0488f37..60802f6 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -100,6 +100,13 @@ SECTIONS
   _edevice = .;
   } :text
 
+  . = ALIGN(8);
+  .adev.info : {
+  _asdevice = .;
+  *(.adev.info)
+  _aedevice = .;
+  } :text
+
   . = ALIGN(PAGE_SIZE); /* Init code and data */
   __init_begin = .;
   .init.text : {
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index a72f7c9..09fcfc3 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -50,6 +50,27 @@ struct device_desc {
 int (*init)(struct dt_device_node *dev, const void *data);
 };
 
+struct acpi_device_desc {
+/* Device name */
+const char *name;
+/* Device class */
+enum device_class class;
+/* type of device supported by the driver */
+const int class_type;
+/* Device initialization */
+int (*init)(const void *data);
+};
+
+/**
+ *  acpi_device_init - Initialize a device
+ *  @class: class of the device (serial, network...)
+ *  @data: specific data for initializing the device
+ *
+ *  Return 0 on success.
+ */
+int __init acpi_device_init(enum device_class class,
+const void *data, int class_type);
+
 /**
  *  device_init - Initialize a device
  *  @dev: device to initialize
@@ -78,6 +99,15 @@ __attribute__((__section__(".dev.info"))) = {
   \
 #define DT_DEVICE_END   \
 };
 
+#define ACPI_DEVICE_START(_name, _namestr, _class)\
+static const struct acpi_device_desc __dev_desc_##_name __used   \
+__attribute__((__section__(".adev.info"))) = {   \
+.name = _namestr,   \
+.class = _class,\
+
+#define ACPI_DEVICE_END   \
+};
+
 #endif /* __ASM_ARM_DEVICE_H */
 
 /*
-- 
1.9.1


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


[Xen-devel] [PATCH v2 15/41] arm : acpi parse GTDT to initialize timer

2015-05-17 Thread Parth Dixit
Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
Using the information presented by GTDT to initialize the arch
timer (not memory-mapped).

Clear all el2 fields in GTDT table after initialization
for passing it to Dom0.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/acpi/boot.c   | 50 ++
 xen/arch/arm/time.c| 38 +--
 xen/include/asm-arm/acpi.h |  2 ++
 3 files changed, 79 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 7d9758f..a8311ae 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -30,6 +30,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 /* Processors with enabled flag and sane MPIDR */
 static int enabled_cpus;
@@ -40,6 +42,54 @@ static bool_t __initdata bootcpu_valid;
 /* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
 static unsigned int total_cpus = 0;
 
+/* Initialize per-processor generic timer */
+void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[])
+{
+int type;
+struct acpi_table_gtdt *gtdt=NULL;
+u8 checksum;
+static const int GTDT_INTRL_TAB[] =
+{
+ACPI_IRQ_TYPE_LEVEL_HIGH,
+ACPI_IRQ_TYPE_EDGE_RISING,
+ACPI_IRQ_TYPE_LEVEL_LOW,
+ACPI_IRQ_TYPE_EDGE_FALLING
+};
+
+acpi_get_table(ACPI_SIG_GTDT, 0, (struct acpi_table_header **)>dt);
+
+if( gtdt )
+{
+/* Initialize all the generic timer IRQ variable from GTDT table */
+
+type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags & 
ACPI_GTDT_INTR_MASK];
+set_irq_type(gtdt->non_secure_el1_interrupt, type);
+generic_timer_irq[TIMER_PHYS_NONSECURE_PPI] =
+gtdt->non_secure_el1_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->secure_el1_flags & ACPI_GTDT_INTR_MASK];
+set_irq_type(gtdt->secure_el1_interrupt, type);
+generic_timer_irq[TIMER_PHYS_SECURE_PPI] =
+gtdt->secure_el1_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags & 
ACPI_GTDT_INTR_MASK];
+set_irq_type(gtdt->non_secure_el2_interrupt, type);
+generic_timer_irq[TIMER_HYP_PPI] =
+gtdt->non_secure_el2_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags & ACPI_GTDT_INTR_MASK];
+set_irq_type(gtdt->virtual_timer_interrupt, type);
+generic_timer_irq[TIMER_VIRT_PPI] =
+gtdt->virtual_timer_interrupt;
+
+gtdt->non_secure_el2_interrupt = 0;
+gtdt->non_secure_el2_flags = 0;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, gtdt), 
gtdt->header.length);
+gtdt->header.checksum -= checksum;
+clean_dcache_va_range(gtdt, sizeof(struct acpi_table_gtdt));
+}
+}
+
 /*
  * acpi_map_gic_cpu_interface - generates a logical cpu number
  * and map to MPIDR represented by GICC structure
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index ce6d3fd..bff95ab 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -64,7 +65,7 @@ unsigned int timer_get_irq(enum timer_ppi ppi)
 static __initdata struct dt_device_node *timer;
 
 /* Set up the timer on the boot CPU (early init function) */
-void __init preinit_xen_time(void)
+static void __init dt_preinit_xen_time(void)
 {
 static const struct dt_device_match timer_ids[] __initconst =
 {
@@ -72,7 +73,6 @@ void __init preinit_xen_time(void)
 { /* sentinel */ },
 };
 int res;
-u32 rate;
 
 timer = dt_find_matching_node(NULL, timer_ids);
 if ( !timer )
@@ -84,8 +84,21 @@ void __init preinit_xen_time(void)
 if ( res )
 panic("Timer: Cannot initialize platform timer");
 
-res = dt_property_read_u32(timer, "clock-frequency", &rate);
-if ( res )
+}
+
+
+
+void __init preinit_xen_time(void)
+{
+u32 rate;
+
+/* Initialize all the generic timers presented in GTDT */
+if ( acpi_disabled )
+dt_preinit_xen_time();
+else
+acpi_preinit_xen_time(timer_irq);
+
+if( acpi_disabled && dt_property_read_u32(timer, "clock-frequency", &rate) 
)
 cpu_khz = rate / 1000;
 else
 cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
@@ -99,14 +112,17 @@ int __init init_xen_time(void)
 int res;
 unsigned int i;
 
-/* Retrieve all IRQs for the timer */
-for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
+if( acpi_disabled )
 {
-res = platform_get_irq(timer, i);
-
-if ( res < 0 )
-panic("Timer: Unable to retrieve IRQ %u from the device tree", i);
-timer_irq[i] = res;
+/* Retrieve all IRQs for the timer */
+for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
+{
+  

[Xen-devel] [PATCH v2 14/41] arm : acpi add helper function for setting interrupt type

2015-05-17 Thread Parth Dixit
set edge/level type information for an interrupt

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/irq.c | 17 +
 xen/include/asm-arm/acpi.h | 26 ++
 xen/include/asm-arm/irq.h  |  2 ++
 3 files changed, 45 insertions(+)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 376c9f2..1713935 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -679,6 +679,23 @@ int platform_get_irq(const struct dt_device_node *device, 
int index)
 return irq;
 }
 
+int set_irq_type(int irq,int type)
+{
+int res;
+
+/* Setup the IRQ type */
+if ( irq < NR_LOCAL_IRQS )
+res = irq_local_set_type(irq, type);
+else
+res = irq_set_spi_type(irq, type);
+
+if ( res )
+return -1;
+
+return 0;
+
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 0845f14..1767143 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -50,4 +50,30 @@ static inline void disable_acpi(void)
 
 #define ACPI_GTDT_INTR_MASK ( ACPI_GTDT_INTERRUPT_MODE | 
ACPI_GTDT_INTERRUPT_POLARITY )
 
+/**
+ * IRQ line type.
+ *
+ * ACPI_IRQ_TYPE_NONE- default, unspecified type
+ * ACPI_IRQ_TYPE_EDGE_RISING - rising edge triggered
+ * ACPI_IRQ_TYPE_EDGE_FALLING- falling edge triggered
+ * ACPI_IRQ_TYPE_EDGE_BOTH   - rising and falling edge triggered
+ * ACPI_IRQ_TYPE_LEVEL_HIGH  - high level triggered
+ * ACPI_IRQ_TYPE_LEVEL_LOW   - low level triggered
+ * ACPI_IRQ_TYPE_LEVEL_MASK  - Mask to filter out the level bits
+ * ACPI_IRQ_TYPE_SENSE_MASK  - Mask for all the above bits
+ * ACPI_IRQ_TYPE_INVALID - Use to initialize the type
+ */
+#define ACPI_IRQ_TYPE_NONE   0x
+#define ACPI_IRQ_TYPE_EDGE_RISING0x0001
+#define ACPI_IRQ_TYPE_EDGE_FALLING   0x0002
+#define ACPI_IRQ_TYPE_EDGE_BOTH   \
+(ACPI_IRQ_TYPE_EDGE_FALLING | ACPI_IRQ_TYPE_EDGE_RISING)
+#define ACPI_IRQ_TYPE_LEVEL_HIGH 0x0004
+#define ACPI_IRQ_TYPE_LEVEL_LOW  0x0008
+#define ACPI_IRQ_TYPE_LEVEL_MASK  \
+(ACPI_IRQ_TYPE_LEVEL_LOW | ACPI_IRQ_TYPE_LEVEL_HIGH)
+#define ACPI_IRQ_TYPE_SENSE_MASK 0x000f
+
+#define ACPI_IRQ_TYPE_INVALID0x0010
+
 #endif /*_ASM_ARM_ACPI_H*/
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 34b492b..ddad0a9 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -51,6 +51,8 @@ void arch_move_irqs(struct vcpu *v);
 /* Set IRQ type for an SPI */
 int irq_set_spi_type(unsigned int spi, unsigned int type);
 
+int set_irq_type(int irq,int type);
+
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
-- 
1.9.1


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


[Xen-devel] [PATCH v2 16/41] acpi : Introduce acpi_parse_entries

2015-05-17 Thread Parth Dixit
add new function acpi_parse_entries which takes
acpi table as argument. This will avoid fetching table
everytime in acpi_table_parse_entries.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/drivers/acpi/tables.c | 60 +--
 xen/include/xen/acpi.h|  3 +++
 2 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 684d8c9..c4c4256 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -237,31 +237,29 @@ void __init acpi_table_print_madt_entry(struct 
acpi_subtable_header *header)
}
 }
 
-
 int __init
-acpi_table_parse_entries(char *id,
-unsigned long table_size,
-int entry_id,
-acpi_table_entry_handler handler,
-unsigned int max_entries)
+acpi_parse_entries(char *id,
+unsigned long table_size,
+acpi_table_entry_handler handler,
+struct acpi_table_header *table_header,
+int entry_id,
+unsigned int max_entries)
 {
-   struct acpi_table_header *table_header = NULL;
-   struct acpi_subtable_header *entry;
+struct acpi_subtable_header *entry;
unsigned int count = 0;
unsigned long table_end;
 
-   if (!handler)
-   return -EINVAL;
+if ( !handler )
+return -EINVAL;
 
-   if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
-   acpi_get_table(id, acpi_apic_instance, &table_header);
-   else
-   acpi_get_table(id, 0, &table_header);
+if ( !table_size )
+return -EINVAL;
 
-   if (!table_header) {
-   printk(KERN_WARNING PREFIX "%4.4s not present\n", id);
-   return -ENODEV;
-   }
+if ( !table_header )
+{
+printk("Table header not present\n");
+return -ENODEV;
+}
 
table_end = (unsigned long)table_header + table_header->length;
 
@@ -292,6 +290,32 @@ acpi_table_parse_entries(char *id,
}
 
return count;
+
+}
+int __init
+acpi_table_parse_entries(char *id,
+unsigned long table_size,
+int entry_id,
+acpi_table_entry_handler handler,
+unsigned int max_entries)
+{
+   struct acpi_table_header *table_header = NULL;
+
+   if (!handler)
+   return -EINVAL;
+
+   if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
+   acpi_get_table(id, acpi_apic_instance, &table_header);
+   else
+   acpi_get_table(id, 0, &table_header);
+
+   if (!table_header) {
+   printk(KERN_WARNING PREFIX "%4.4s not present\n", id);
+   return -ENODEV;
+   }
+
+return acpi_parse_entries(id, table_size, handler, table_header,
+entry_id, max_entries);
 }
 
 int __init
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index ee6a5ea..3eafd1f 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -74,6 +74,9 @@ int acpi_table_init (void);
 int acpi_table_parse(char *id, acpi_table_handler handler);
 int acpi_table_parse_entries(char *id, unsigned long table_size,
int entry_id, acpi_table_entry_handler handler, unsigned int 
max_entries);
+int acpi_parse_entries(char *id, unsigned long table_size,
+acpi_table_entry_handler handler, struct acpi_table_header *table_header,
+int entry_id, unsigned int max_entries);
 int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler 
handler, unsigned int max_entries);
 int acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
unsigned int max_entries);
-- 
1.9.1


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


[Xen-devel] [PATCH v2 10/41] arm/acpi : Print GIC information when MADT is parsed

2015-05-17 Thread Parth Dixit
From: Naresh Bhat 

When MADT is parsed, print GIC information to make the boot
log look pretty.

Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Naresh Bhat 
---
 xen/drivers/acpi/tables.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 1beca79..684d8c9 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -190,6 +190,45 @@ void __init acpi_table_print_madt_entry(struct 
acpi_subtable_header *header)
}
break;
 
+case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
+{
+struct acpi_madt_generic_interrupt *p =
+(struct acpi_madt_generic_interrupt *)header;
+printk(KERN_INFO PREFIX
+"GIC (acpi_id[0x%04x] gic_id[0x%04x] %s)\n",
+p->uid, p->gic_id,
+(p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
+}
+break;
+
+case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
+{
+struct acpi_madt_generic_distributor *p =
+(struct acpi_madt_generic_distributor *)header;
+printk(KERN_INFO PREFIX
+"GIC Distributor (id[0x%04x] address[0x%08llx] 
gsi_base[%d])\n",
+p->gic_id, (long long unsigned int)p->base_address, 
p->global_irq_base);
+}
+break;
+
+case ACPI_MADT_TYPE_GIC_MSI_FRAME:
+{
+struct acpi_madt_gic_msi_frame *p =
+(struct acpi_madt_gic_msi_frame *)header;
+printk("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
+(long long unsigned int)p->base_address, p->gic_msi_frame_id);
+}
+break;
+
+case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
+{
+struct acpi_madt_gic_redistributor *p =
+(struct acpi_madt_gic_redistributor *)header;
+printk("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
+(long long unsigned int)p->base_address, p->region_size);
+}
+break;
+
default:
printk(KERN_WARNING PREFIX
   "Found unsupported MADT entry (type = %#x)\n",
-- 
1.9.1


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


[Xen-devel] [PATCH v2 09/41] arm/acpi : Add Generic Interrupt and Distributor struct

2015-05-17 Thread Parth Dixit
Add Generic Interrupt and Distributor (ACPI 5.0) structure.
Add new features for MADT introduced by ACPI 5.1.
Comment on the GIC ID field of the GIC structure which is replaced
by CPU Interface Number.
Add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
Add new structures for GIC MSI frame and GICR.
Add flag definition for GICC flags.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/include/acpi/actbl1.h | 62 +--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
index 9311e3a..2d72d8a 100644
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -639,7 +639,11 @@ enum acpi_madt_type {
ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
-   ACPI_MADT_TYPE_RESERVED = 11/* 11 and greater are reserved */
+   ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
+   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
+   ACPI_MADT_TYPE_GIC_MSI_FRAME = 13,
+   ACPI_MADT_TYPE_GIC_REDISTRIBUTOR = 14,
+   ACPI_MADT_TYPE_RESERVED = 15/* 15 and greater are reserved */
 };
 
 /*
@@ -760,14 +764,68 @@ struct acpi_madt_local_x2apic_nmi {
u8 reserved[3];
 };
 
+/* 11: Generic Interrupt (ACPI 5.1) */
+
+struct acpi_madt_generic_interrupt {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u32 gic_id; /* it was renamed to cpu interface number in ACPI 5.1 */
+u32 uid;
+u32 flags;
+u32 parking_version;
+u32 performance_interrupt;
+u64 parked_address;
+u64 base_address;
+u64 gicv_base_address;
+u64 gich_base_address;
+u32 vgic_maintenance_interrupt;
+u64 redist_base_address;
+u64 mpidr;
+
+};
+
+/* 12: Generic Distributor (ACPI 5.0) */
+
+struct acpi_madt_generic_distributor {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u32 gic_id;
+u64 base_address;
+u32 global_irq_base;
+u32 reserved2;  /* reserved - must be zero */
+};
+
+/* 13: GIC MSI Frame (ACPI 5.1) */
+
+struct acpi_madt_gic_msi_frame {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u32 gic_msi_frame_id;
+u64 base_address;
+};
+
+/* 14: GIC Redistributor (ACPI 5.1) */
+
+struct acpi_madt_gic_redistributor {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u64 base_address;
+u32 region_size;
+};
+
 /*
  * Common flags fields for MADT subtables
  */
 
-/* MADT Local APIC flags (lapic_flags) */
+/* MADT Local APIC flags (lapic_flags) and GICC flags */
 
 #define ACPI_MADT_ENABLED   (1)/* 00: Processor is usable if 
set */
 
+/* MADT GICC flags only */
+
+#define ACPI_MADT_PERF_INT_MODE (1<<1) /* 01: Performance Interrupt 
Mode */
+#define ACPI_MADT_VGIC  (1<<2) /* 02: VGIC Maintenance 
interrupt mode */
+
 /* MADT MPS INTI flags (inti_flags) */
 
 #define ACPI_MADT_POLARITY_MASK (3)/* 00-01: Polarity of APIC I/O 
input signals */
-- 
1.9.1


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


[Xen-devel] [PATCH v2 11/41] arm/acpi : add GTDT support updated by ACPI 5.1

2015-05-17 Thread Parth Dixit
With ACPI 5.0, we got per-processor timer support in GTDT,
and ACPI 5.1 introduced the support for platform (memory-mapped)
timers: GT Block and SBSA watchdog timer, add the code needed
for the spec change.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/include/acpi/actbl3.h  | 92 +++---
 xen/include/asm-arm/acpi.h |  2 +
 2 files changed, 80 insertions(+), 14 deletions(-)

diff --git a/xen/include/acpi/actbl3.h b/xen/include/acpi/actbl3.h
index 8c61b5f..7664f9d 100644
--- a/xen/include/acpi/actbl3.h
+++ b/xen/include/acpi/actbl3.h
@@ -241,33 +241,97 @@ struct acpi_s3pt_suspend {
 
 
/***
  *
- * GTDT - Generic Timer Description Table (ACPI 5.0)
+ * GTDT - Generic Timer Description Table (ACPI 5.1)
  *Version 1
  *
  
**/
 
 struct acpi_table_gtdt {
struct acpi_table_header header;/* Common ACPI table header */
-   u64 address;
-   u32 flags;
-   u32 secure_pl1_interrupt;
-   u32 secure_pl1_flags;
-   u32 non_secure_pl1_interrupt;
-   u32 non_secure_pl1_flags;
+   u64 cnt_control_base_address;
+   u32 reserved;
+   u32 secure_el1_interrupt;
+   u32 secure_el1_flags;
+   u32 non_secure_el1_interrupt;
+   u32 non_secure_el1_flags;
u32 virtual_timer_interrupt;
u32 virtual_timer_flags;
-   u32 non_secure_pl2_interrupt;
-   u32 non_secure_pl2_flags;
+   u32 non_secure_el2_interrupt;
+   u32 non_secure_el2_flags;
+   u64 cnt_read_base_address;
+   u32 platform_timer_count;
+   u32 platform_timer_offset;
 };
 
-/* Values for Flags field above */
+/* Values for all "TimerFlags" fields above */
 
-#define ACPI_GTDT_MAPPED_BLOCK_PRESENT  1
+#define ACPI_GTDT_INTERRUPT_MODE( 1 << 0 )
+#define ACPI_GTDT_INTERRUPT_POLARITY( 1 << 1 )
 
-/* Values for all "TimerFlags" fields above */
+#define ACPI_GTDT_ALWAYS_ON ( 1 << 2 )
+
+/* Values for GTDT subtable type in struct acpi_subtable_header */
+
+enum acpi_gtdt_type {
+ACPI_GTDT_TYPE_GT_BLOCK = 0,/* memory-mapped generic timer */
+ACPI_GTDT_TYPE_SBSA_GENERIC_WATCHDOG = 1,
+ACPI_GTDT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
+};
+
+/*
+ * GTDT Subtables, correspond to Type in struct acpi_subtable_header
+ */
+
+/* 0: Generic Timer Block */
+
+struct acpi_gtdt_gt_block {
+struct acpi_subtable_header header;
+u16 reserved;
+u64 gt_block_address;
+u32 gt_block_timer_count;   /* must be less than or equal to 8 */
+u32 gt_block_timer_offset;
+};
+
+/* GT Block Timer Structure */
+
+struct acpi_gt_block_timer {
+u8 gt_frame_number;
+u8 reseved[3];
+u64 cnt_base_address;
+u64 cnt_el0_base_adress;
+u32 physical_timer_interrupt;
+u32 physical_timer_flags;
+u32 vitual_timer_interrupt;
+u32 vitual_timer_flags;
+u32 timer_common_flags;
+};
+
+/* Flag Definitions: GT Block Physical Timers and Virtual timers */
+
+#define ACPI_GT_BLOCK_INTERRUPT_MODE   ( 1 << 0 )
+#define ACPI_GT_BLOCK_INTERRUPT_POLARITY   ( 1 << 1 )
+
+/* Flag Definitions: Common Flags */
+
+#define ACPI_GT_BLOCK_IS_SECURE_TIMER  ( 1 << 0 )
+#define ACPI_GT_BLOCK_ALWAYS_ON( 1 << 1 )
+
+/* 1: SBSA Generic Watchdog Structure */
+
+struct acpi_sbsa_generic_watchdog {
+struct acpi_subtable_header header;
+u16 reserved;
+u64 refresh_frame_address;
+u64 control_frame_address;
+u32 interrupt;
+u32 flags;
+};
+
+/* Flag Definitions: SBSA Generic Watchdog */
 
-#define ACPI_GTDT_INTERRUPT_MODE1
-#define ACPI_GTDT_INTERRUPT_POLARITY2
+#define ACPI_SBSA_WATCHDOG_INTERRUPT_MODE  ( 1 << 0 )
+#define ACPI_SBSA_WATCHDOG_INTERRUPT_POLARITY  ( 1 << 1 )
+#define ACPI_SBSA_WATCHDOG_IS_SECURE_TIMER ( 1 << 2 )
 
 
/***
  *
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 058f343..4a6cb37 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -46,4 +46,6 @@ static inline void disable_acpi(void)
 acpi_disabled = 1;
 }
 
+#define ACPI_GTDT_INTR_MASK ( ACPI_GTDT_INTERRUPT_MODE | 
ACPI_GTDT_INTERRUPT_POLARITY )
+
 #endif /*_ASM_ARM_ACPI_H*/
-- 
1.9.1


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


[Xen-devel] [PATCH v2 12/41] arm : move dt specific code in smp to seperate functions

2015-05-17 Thread Parth Dixit
partition smp initialization functions into generic and dt
specific parts, this will be useful when introducing new
functions for smp initialization based on acpi

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/arm64/smpboot.c |  7 ++-
 xen/arch/arm/smpboot.c   | 28 +---
 2 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 62e6abb..7928f69 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -70,7 +70,7 @@ int __init arch_smp_init(void)
 return 0;
 }
 
-int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
+static int __init dt_arch_cpu_init(int cpu, struct dt_device_node *dn)
 {
 const char *enable_method;
 
@@ -94,6 +94,11 @@ int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
 return 0;
 }
 
+int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
+{
+return dt_arch_cpu_init(cpu, dn);
+}
+
 int __init arch_cpu_up(int cpu)
 {
 if ( !smp_enable_ops[cpu].prepare_cpu )
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index a96cda2..90f9ef2 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -92,7 +92,7 @@ smp_clear_cpu_maps (void)
  * MPIDR values related to logical cpus
  * Code base on Linux arch/arm/kernel/devtree.c
  */
-void __init smp_init_cpus(void)
+static void __init dt_smp_init_cpus(void)
 {
 register_t mpidr;
 struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
@@ -106,16 +106,6 @@ void __init smp_init_cpus(void)
 bool_t bootcpu_valid = 0;
 int rc;
 
-/* scan the DTB for a PSCI node and set a global variable */
-psci_init();
-
-if ( (rc = arch_smp_init()) < 0 )
-{
-printk(XENLOG_WARNING "SMP init failed (%d)\n"
-   "Using only 1 CPU\n", rc);
-return;
-}
-
 mpidr = boot_cpu_data.mpidr.bits & MPIDR_HWID_MASK;
 
 if ( !cpus )
@@ -243,6 +233,22 @@ void __init smp_init_cpus(void)
 }
 }
 
+void __init smp_init_cpus(void)
+{
+int rc;
+/* initialize PSCI and set a global variable */
+psci_init();
+
+if ( (rc = arch_smp_init()) < 0 )
+{
+printk(XENLOG_WARNING "SMP init failed (%d)\n"
+   "Using only 1 CPU\n", rc);
+return;
+}
+
+dt_smp_init_cpus();
+}
+
 int __init
 smp_get_max_cpus (void)
 {
-- 
1.9.1


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


[Xen-devel] [PATCH v2 13/41] arm/acpi : parse MADT to map logical cpu to MPIDR and get cpu_possible_map

2015-05-17 Thread Parth Dixit
MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map.

Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/acpi/boot.c | 135 +++
 xen/arch/arm/arm64/smpboot.c |   7 ++-
 xen/arch/arm/psci.c  |  16 +
 xen/arch/arm/smpboot.c   |   7 ++-
 xen/include/asm-arm/acpi.h   |   2 +
 xen/include/xen/acpi.h   |   5 ++
 6 files changed, 170 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 57eb33c..7d9758f 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -29,6 +29,141 @@
 #include 
 
 #include 
+#include 
+
+/* Processors with enabled flag and sane MPIDR */
+static int enabled_cpus;
+
+/* Boot CPU is valid or not in MADT */
+static bool_t __initdata bootcpu_valid;
+
+/* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
+static unsigned int total_cpus = 0;
+
+/*
+ * acpi_map_gic_cpu_interface - generates a logical cpu number
+ * and map to MPIDR represented by GICC structure
+ * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
+ * @enabled: this cpu is enabled or not
+ *
+ * Returns the logical cpu number which maps to MPIDR
+ */
+static int __init acpi_map_gic_cpu_interface(u64 mpidr, u8 enabled)
+{
+int i;
+
+if ( mpidr == MPIDR_INVALID )
+{
+printk("Skip MADT cpu entry with invalid MPIDR\n");
+return -EINVAL;
+}
+
+total_cpus++;
+if ( !enabled )
+return -EINVAL;
+
+if ( enabled_cpus >=  NR_CPUS )
+{
+printk("NR_CPUS limit of %d reached, Processor %d/0x%"PRIx64" 
ignored.\n",
+NR_CPUS, total_cpus, mpidr);
+return -EINVAL;
+}
+
+/* Check if GICC structure of boot CPU is available in the MADT */
+if ( cpu_logical_map(0) == mpidr )
+{
+if ( bootcpu_valid )
+{
+printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in MADT\n",
+mpidr);
+return -EINVAL;
+}
+
+bootcpu_valid = TRUE;
+}
+
+/*
+ * Duplicate MPIDRs are a recipe for disaster. Scan
+ * all initialized entries and check for
+ * duplicates. If any is found just ignore the CPU.
+ */
+for ( i = 1; i < enabled_cpus; i++ )
+{
+if ( cpu_logical_map(i) == mpidr )
+{
+printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in MADT\n",
+mpidr);
+return -EINVAL;
+}
+}
+
+if ( !acpi_psci_present() )
+return -EOPNOTSUPP;
+
+/* CPU 0 was already initialized */
+if ( enabled_cpus )
+{
+if ( arch_cpu_init(enabled_cpus, NULL) < 0 )
+return -EOPNOTSUPP;
+
+/* map the logical cpu id to cpu MPIDR */
+cpu_logical_map(enabled_cpus) = mpidr;
+}
+
+enabled_cpus++;
+return enabled_cpus;
+}
+
+static int __init
+acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+
+if ( BAD_MADT_ENTRY(processor, end) )
+return -EINVAL;
+
+acpi_table_print_madt_entry(header);
+
+acpi_map_gic_cpu_interface(processor->mpidr & MPIDR_HWID_MASK,
+processor->flags & ACPI_MADT_ENABLED);
+
+return 0;
+}
+
+/* Parse GIC cpu interface entries in MADT for SMP init */
+void __init acpi_init_cpus(void)
+{
+int count, i;
+
+/*
+ * do a partial walk of MADT to determine how many CPUs
+ * we have including disabled CPUs, and get information
+ * we need for SMP init
+ */
+count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+acpi_parse_gic_cpu_interface, 0);
+
+if ( count < 0 )
+{
+printk("Error parsing GIC CPU interface entry\n");
+return;
+}
+
+if ( !bootcpu_valid )
+{
+printk("MADT missing boot CPU MPIDR, not enabling secondaries\n");
+return;
+}
+
+for ( i = 0; i < enabled_cpus; i++ )
+cpumask_set_cpu(i, &cpu_possible_map);
+
+/* Make boot-up look pretty */
+printk("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
+}
 
 static int __init acpi_parse_fadt(struct acpi_table_header *table)
 {
diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 7928f69..c3d9e00 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct smp_enable_ops {
   

[Xen-devel] [PATCH v2 08/41] arm/acpi : Parse FADT table and get PSCI flags

2015-05-17 Thread Parth Dixit
There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the hardware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).

FADT table contains such information, parse FADT to get the flags
for furture usage. At the same time, only ACPI 5.1 or higher verison
supports PSCI, and FADT Major.Minor version was introduced in ACPI
5.1, so we will check the version and only parse FADT table with
version >= 5.1.

If firmware provides ACPI tables with ACPI version less than 5.1,
OS will be messed up with those information, so disable ACPI if we
get an FADT table with version less that 5.1.

Modify FADT table before passing it to Dom0.
Set PSCI_COMPLIANT and PSCI_USE_HVC.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/acpi/boot.c   | 38 ++
 xen/arch/arm/acpi/lib.c| 11 +++
 xen/include/asm-arm/acpi.h | 11 +++
 3 files changed, 60 insertions(+)

diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 8dc69d5..57eb33c 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -24,9 +24,40 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
+u8 checksum;
+
+/*
+ * Revision in table header is the FADT Major revision, and there
+ * is a minor revision of FADT which was introduced by ACPI 5.1,
+ * we only deal with ACPI 5.1 or newer revision to get GIC and SMP
+ * boot protocol configuration data, or we will disable ACPI.
+ */
+if ( table->revision > 5 ||
+( table->revision == 5 && fadt->minor_revision >= 1 ) )
+{
+fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT | 
ACPI_FADT_PSCI_USE_HVC );
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), 
fadt->header.length);
+fadt->header.checksum -= checksum;
+clean_dcache_va_range(fadt, sizeof(struct acpi_table_fadt));
+return 0;
+}
+
+printk("Unsupported FADT revision %d.%d, should be 5.1+, will disable 
ACPI\n",
+table->revision, fadt->minor_revision);
+disable_acpi();
+
+return -EINVAL;
+}
+
 /*
  * acpi_boot_table_init() called from setup_arch(), always.
  *  1. find RSDP and get its address, and then find XSDT
@@ -51,6 +82,13 @@ int __init acpi_boot_table_init(void)
 return error;
 }
 
+if ( acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt) )
+{
+/* disable ACPI if no FADT is found */
+disable_acpi();
+printk("Can't find FADT\n");
+}
+
 return 0;
 }
 
diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index 650beed..fd9bfa4 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -6,3 +6,14 @@ acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
 {
 return __va(phys);
 }
+/* 1 to indicate PSCI 0.2+ is implemented */
+inline bool_t acpi_psci_present(void)
+{
+return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT;
+}
+
+/* 1 to indicate HVC is present instead of SMC as the PSCI conduit */
+inline bool_t acpi_psci_hvc_present(void)
+{
+return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
+}
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index f771056..058f343 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -29,6 +29,17 @@
 #define COMPILER_DEPENDENT_UINT64  unsigned long long
 
 extern bool_t acpi_disabled;
+
+#ifdef CONFIG_ACPI
+/* 1 to indicate PSCI 0.2+ is implemented */
+bool_t acpi_psci_present(void);
+/* 1 to indicate HVC is present instead of SMC as the PSCI conduit */
+bool_t acpi_psci_hvc_present(void);
+#else
+static inline bool_t acpi_psci_present(void) { return false; }
+static inline bool_t acpi_psci_hvc_present(void) {return false; }
+#endif /* CONFIG_ACPI */
+
 /* Basic configuration for ACPI */
 static inline void disable_acpi(void)
 {
-- 
1.9.1


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


[Xen-devel] [PATCH v2 07/41] arm/acpi : Introduce ARM Boot Architecture Flags in FADT

2015-05-17 Thread Parth Dixit
The Power State Coordination Interface (PSCI) defines an API that
can be used to coordinate power control amongst the various supervisory
systems concurrently running on a device. ACPI support for this
technology would require the addition of two flags: PSCI_COMPLIANT and
PSCI_USE_HVC. When set, the former signals to the OS that the hardware
is PSCI compliant. The latter selects the appropriate conduit for PSCI
calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
Calls (SMC).

An ARM Boot Architecture Flags structure to support new ARM hardware
was introduced in FADT in ACPI 5.1, add the code accordingly to
implement that in ACPICA core.

Since ACPI 5.1 doesn't support self defined PSCI function IDs,
which means that only PSCI 0.2+ is supported in ACPI.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
 xen/include/acpi/actbl.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
index 856945d..96fd1d8 100644
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -244,7 +244,8 @@ struct acpi_table_fadt {
u32 flags;  /* Miscellaneous flag bits (see below for 
individual flags) */
struct acpi_generic_address reset_register; /* 64-bit address of 
the Reset register */
u8 reset_value; /* Value to write to the reset_register port to 
reset the system */
-   u8 reserved4[3];/* Reserved, must be zero */
+u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below for 
individual flags) */
+u8 minor_revision;   /* Minor version of this FADT structure */
u64 Xfacs;  /* 64-bit physical address of FACS */
u64 Xdsdt;  /* 64-bit physical address of DSDT */
struct acpi_generic_address xpm1a_event_block;  /* 64-bit Extended 
Power Mgt 1a Event Reg Blk address */
@@ -270,6 +271,11 @@ struct acpi_table_fadt {
 
 #define FADT2_REVISION_ID   3
 
+/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
+
+#define ACPI_FADT_PSCI_COMPLIANT(1)/* 00: PSCI 0.2+ is implemented 
*/
+#define ACPI_FADT_PSCI_USE_HVC  (1<<1) /* 01: HVC must be used instead 
of SMC as the PSCI conduit */
+
 /* Masks for FADT flags */
 
 #define ACPI_FADT_WBINVD(1)/* 00: [V1] The wbinvd 
instruction works properly */
@@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
  * FADT V5  size: 0x10C
  */
 #define ACPI_FADT_V1_SIZE   (u32) (ACPI_FADT_OFFSET (flags) + 4)
-#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
+#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (arm_boot_flags) + 3)
 #define ACPI_FADT_V3_SIZE   (u32) (ACPI_FADT_OFFSET (sleep_control))
 #define ACPI_FADT_V5_SIZE   (u32) (sizeof (struct acpi_table_fadt))
 
-- 
1.9.1


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


[Xen-devel] [PATCH v2 03/41] arm/acpi : emulate io ports for arm

2015-05-17 Thread Parth Dixit
add macros to emulate x86 style ports for arm.
This avoids modification in common code for acpi.

Signed-off-by: Parth Dixit 
---
 xen/include/asm-arm/arm64/io.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/include/asm-arm/arm64/io.h b/xen/include/asm-arm/arm64/io.h
index 37abc47..7ad9b65 100644
--- a/xen/include/asm-arm/arm64/io.h
+++ b/xen/include/asm-arm/arm64/io.h
@@ -20,6 +20,7 @@
 #ifndef _ARM_ARM64_IO_H
 #define _ARM_ARM64_IO_H
 
+#include 
 #include 
 
 /*
@@ -109,4 +110,17 @@ static inline u64 __raw_readq(const volatile void __iomem 
*addr)
 #define writel(v,c) ({ __iowmb(); writel_relaxed((v),(c)); })
 #define writeq(v,c) ({ __iowmb(); writeq_relaxed((v),(c)); })
 
+/*
+ * Emulate x86 io ports for arm.
+ */
+#define __armio(addr) ( (void __iomem *)addr )
+
+#define inb(c) ( readb( __armio(c) ) )
+#define inw(c) ( readw( __armio(c) ) )
+#define inl(c) ( readl( __armio(c) ) )
+
+#define outb(v, c) ( writeb(v, __armio(c) ) )
+#define outw(v, c) ( writew(v, __armio(c) ) )
+#define outl(v, c) ( writel(v, __armio(c) ) )
+
 #endif /* _ARM_ARM64_IO_H */
-- 
1.9.1


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


[Xen-devel] [PATCH v2 04/41] arm/acpi : add arm specific acpi header file

2015-05-17 Thread Parth Dixit
add architecture specific definitions and calls
required for acpi in new header file

Signed-off-by: Parth Dixit 
---
 xen/include/asm-arm/acpi.h | 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 xen/include/asm-arm/acpi.h

diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
new file mode 100644
index 000..f771056
--- /dev/null
+++ b/xen/include/asm-arm/acpi.h
@@ -0,0 +1,38 @@
+/*
+ *  Copyright (C) 2014, Naresh Bhat 
+ *
+ * ~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~
+ */
+
+#ifndef _ASM_ARM64_ACPI_H
+#define _ASM_ARM64_ACPI_H
+
+#include 
+
+#define COMPILER_DEPENDENT_INT64   long long
+#define COMPILER_DEPENDENT_UINT64  unsigned long long
+
+extern bool_t acpi_disabled;
+/* Basic configuration for ACPI */
+static inline void disable_acpi(void)
+{
+acpi_disabled = 1;
+}
+
+#endif /*_ASM_ARM_ACPI_H*/
-- 
1.9.1


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


[Xen-devel] [PATCH v2 05/41] acpi : add helper function for mapping memory

2015-05-17 Thread Parth Dixit
common acpi code for memory mapping is specific to x86.
Add a new helper function for mapping memory based on architecture.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/Makefile  |  1 +
 xen/arch/arm/acpi/Makefile |  1 +
 xen/arch/arm/acpi/lib.c|  8 
 xen/arch/x86/acpi/lib.c| 15 +++
 xen/drivers/acpi/osl.c | 11 +--
 xen/include/xen/acpi.h |  2 ++
 6 files changed, 28 insertions(+), 10 deletions(-)
 create mode 100644 xen/arch/arm/acpi/Makefile
 create mode 100644 xen/arch/arm/acpi/lib.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 935999e..096e9ef 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
 subdir-$(arm64) += arm64
 subdir-y += platforms
 subdir-$(arm64) += efi
+subdir-$(HAS_ACPI) += acpi
 
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += cpu.o
diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
new file mode 100644
index 000..b5be22d
--- /dev/null
+++ b/xen/arch/arm/acpi/Makefile
@@ -0,0 +1 @@
+obj-y += lib.o
diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
new file mode 100644
index 000..650beed
--- /dev/null
+++ b/xen/arch/arm/acpi/lib.c
@@ -0,0 +1,8 @@
+#include 
+#include 
+
+void __iomem *
+acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
+{
+return __va(phys);
+}
diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
index 1f98c31..cb1b98e 100644
--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -34,6 +34,21 @@ u8 __read_mostly acpi_disable_value;
 u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
 {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
 
+void __iomem *
+acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
+{
+if (system_state >= SYS_STATE_active) {
+unsigned long pfn = PFN_DOWN(phys);
+unsigned int offs = phys & (PAGE_SIZE - 1);
+
+/* The low first Mb is always mapped. */
+if ( !((phys + size - 1) >> 20) )
+return __va(phys);
+return __vmap(&pfn, PFN_UP(offs + size), 1, 1, 
PAGE_HYPERVISOR_NOCACHE) + offs;
+   }
+return __acpi_map_table(phys, size);
+}
+
 /*
  * Important Safety Note:  The fixed ACPI page numbers are *subtracted*
  * from the fixed base.  That's why we start at FIX_ACPI_END and
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 93c983c..958caae 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -87,16 +87,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-   if (system_state >= SYS_STATE_active) {
-   unsigned long pfn = PFN_DOWN(phys);
-   unsigned int offs = phys & (PAGE_SIZE - 1);
-
-   /* The low first Mb is always mapped. */
-   if ( !((phys + size - 1) >> 20) )
-   return __va(phys);
-   return __vmap(&pfn, PFN_UP(offs + size), 1, 1, 
PAGE_HYPERVISOR_NOCACHE) + offs;
-   }
-   return __acpi_map_table(phys, size);
+return acpi_os_map_iomem(phys, size);
 }
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 3aeba4a..afe2dca 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -55,6 +55,8 @@ typedef int (*acpi_table_handler) (struct acpi_table_header 
*table);
 
 typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, 
const unsigned long end);
 
+void __iomem *
+acpi_os_map_iomem(acpi_physical_address phys, acpi_size size);
 unsigned int acpi_get_processor_id (unsigned int cpu);
 char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
 int acpi_boot_init (void);
-- 
1.9.1


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


  1   2   >