[PATCH v2 00/41] Add ACPI support for arm64 on Xen

[PATCH v2 00/41] Add ACPI support for arm64 on Xen

[Parth Dixit]

This patch series adds ACPI support for arm64.
Xen reads static tables described by ACPI standard (5.1) from uefi
and configures timer, gic and uart. ACPI tables are modified to 
enable PSCI, HVC and xen specific information (grant table and 
event channel interrupts) and mapped into dom0 address space.
A skeleton device tree is created to pass efi table which contains
memory layout (which cannot be passed using ACPI) and rsdp pointer to DOM0.
DOM0 parses dynamic ACPI tables and configure other peripherals.

Patches 1-21 add ACPI support for xen/uefi interface
Patches 22-41 add ACPI support for xen/Dom0 interface
Last patch "xen: arm64: Add ACPI support" enables the support for ACPI
so that individual patches do not affect working xen code base.

Patches are tested on FVP base model and same binary is working for ACPI as well as
device tree.(32 bit is not tested).

ACPI is now configurable via commandline option "acpi".
To boot from ACPI this parameter should be set to "force".

Instructions for reproducing the setup and working code base can be found 
in the following repositories
wiki : https://wiki.linaro.org/LEG/Engineering/Xen_boot_on_FVP_ACPI_UEFI
linux : https://git.linaro.org/people/parth.dixit/xen-upstreaming/leg-kernel.git
xen : https://git.linaro.org/people/parth.dixit/xen-upstreaming/xen.git
uefi : https://git.linaro.org/people/parth.dixit/xen-acpi-support/linaro-edk2.git

Few workarounds have been made to get it working, these are as follows
1. In Xen interrupts are routed at the boot time with edge/trigger level set to 0
because this information is not available at the time of booting.

2. EFI runtime services are disaled in linux but proper solution has to come from linux side.

-------------------------------------------------------
Chanhelog v2
- ACPI configuration is now divided into two patches
- disabling numa is a seperate patch
- build pmstat is a seperate patch
- new patch for emulation io ports for arm in acpi
- refactoring of memory mapping code to arch specific mapping
- added new file boot.c and lib.c for acpi
- merged FADT parsing and modifcation into single patch
- divided smp functions into common and dt specific parts
- added smp support to ACPI
- divided gtdt functions to common and dt specific parts
- cleared el2 fields before passing to dom0
- refactored acpi parse entries
- refactored gic into common and dt specific parts
- added new framework for initializing acpi devices
- modified GICH and ICV values which are not relevant to Dom0
- renamed dt-uart.c to arm-uart.c
- refctored pl011 init
- added initrd support to dt stub
- new function to add efi node
- added new efi structures to common efi file
- marked ACPI memory in dom0 as reserved
- added new functions for estimating efi size
- added new function to dynamically map mmio's
- changed function names from map_acpi to prepare_acpi
- added new function for calculating crc32 by Igor Pavlov
- memory and rsdp is passed via efi table
- added new acpi parameter which needs to be set to enable acpi
- enabled efi 
-------------------------------------------


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

 config/arm64.mk                |   1 +
 xen/arch/arm/Makefile          |   1 +
 xen/arch/arm/acpi/Makefile     |   2 +
 xen/arch/arm/acpi/boot.c       | 279 +++++++++++++++++++++
 xen/arch/arm/acpi/lib.c        |  31 +++
 xen/arch/arm/arm64/smpboot.c   |  12 +-
 xen/arch/arm/device.c          |  19 ++
 xen/arch/arm/domain_build.c    | 551 ++++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/efi/efi-boot.h    |  20 +-
 xen/arch/arm/gic-v2.c          | 143 ++++++++++-
 xen/arch/arm/gic.c             |  23 +-
 xen/arch/arm/irq.c             |  17 ++
 xen/arch/arm/kernel.c          |   5 +-
 xen/arch/arm/kernel.h          |   1 +
 xen/arch/arm/p2m.c             |  26 ++
 xen/arch/arm/psci.c            |  16 ++
 xen/arch/arm/setup.c           |  43 +++-
 xen/arch/arm/smpboot.c         |  33 ++-
 xen/arch/arm/time.c            |  38 ++-
 xen/arch/arm/traps.c           |  51 +++-
 xen/arch/arm/vgic.c            |  18 ++
 xen/arch/arm/xen.lds.S         |   7 +
 xen/arch/x86/acpi/lib.c        |  15 ++
 xen/common/efi/boot.c          |   2 +
 xen/common/efi/runtime.c       |   2 +-
 xen/common/sysctl.c            |   2 +
 xen/drivers/acpi/Makefile      |   4 +-
 xen/drivers/acpi/osl.c         |  11 +-
 xen/drivers/acpi/tables.c      |  99 ++++++--
 xen/drivers/char/Makefile      |   2 +-
 xen/drivers/char/arm-uart.c    | 136 ++++++++++
 xen/drivers/char/dt-uart.c     | 107 --------
 xen/drivers/char/pl011.c       |  96 +++++--
 xen/include/acpi/actbl.h       |  10 +-
 xen/include/acpi/actbl1.h      |  62 ++++-
 xen/include/acpi/actbl2.h      |  39 +++
 xen/include/acpi/actbl3.h      |  92 +++++--
 xen/include/asm-arm/acpi.h     |  95 +++++++
 xen/include/asm-arm/arm64/io.h |  14 ++
 xen/include/asm-arm/config.h   |   5 +
 xen/include/asm-arm/device.h   |  30 +++
 xen/include/asm-arm/irq.h      |   2 +
 xen/include/asm-arm/p2m.h      |  10 +
 xen/include/asm-arm/setup.h    |   1 +
 xen/include/xen/acpi.h         |  10 +
 xen/include/xen/efi.h          |  67 ++++-
 xen/include/xen/serial.h       |   3 +-
 47 files changed, 2038 insertions(+), 215 deletions(-)
 create mode 100644 xen/arch/arm/acpi/Makefile
 create mode 100644 xen/arch/arm/acpi/boot.c
 create mode 100644 xen/arch/arm/acpi/lib.c
 create mode 100644 xen/drivers/char/arm-uart.c
 delete mode 100644 xen/drivers/char/dt-uart.c
 create mode 100644 xen/include/asm-arm/acpi.h

-- 
1.9.1

[PATCH v2 01/41] arm/acpi: Build numa for x86 only

[Parth Dixit]

From: Naresh Bhat <naresh.bhat@linaro.org>

Numa is currently not supported for arm in xen.
Configure and build numa for x86 architecture only.

Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 xen/drivers/acpi/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index bbb06a7..7294b5a 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -3,7 +3,7 @@ subdir-y += utilities
 subdir-$(x86) += apei
 
 obj-bin-y += tables.init.o
-obj-y += numa.o
+obj-$(x86) += numa.o
 obj-y += osl.o
 obj-y += pmstat.o
 
-- 
1.9.1

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

[Julien Grall]

Hi Parth,

On 17/05/15 21:03, Parth Dixit wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
> 
> Numa is currently not supported for arm in xen.
> Configure and build numa for x86 architecture only.
> 
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
Reviewed-by: Julien Grall <julien.grall@citrix.com>

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
> 
> Numa is currently not supported for arm in xen.

This doesn't represent a valid reason for the code to be disabled,
the more that ARM will want to support NUMA sooner or later. A
valid reason would be if you'd have to introduce _a lot_ of code on
the ARM side in order to make this build - if that's the case, please
say so in the description, as from an architectural pov the absence
of the respective ACPI tables should be no issue at all.

Jan

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

[Julien Grall]

On 20/05/15 16:07, Jan Beulich wrote:
>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>
>> Numa is currently not supported for arm in xen.
> 
> This doesn't represent a valid reason for the code to be disabled,
> the more that ARM will want to support NUMA sooner or later. A
> valid reason would be if you'd have to introduce _a lot_ of code on
> the ARM side in order to make this build - if that's the case, please
> say so in the description, as from an architectural pov the absence
> of the respective ACPI tables should be no issue at all.

The acpi/numa.c is calling a lot of arch specific function implemented
in (arch/x86/srat.c). The code in acpi/numa.c is very x86 related (such
as x2apic).

I think disable the compilation is preferable for now given that there
is no board for testing the changes.

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 20.05.15 at 17:21, <julien.grall@citrix.com> wrote:
> On 20/05/15 16:07, Jan Beulich wrote:
>>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>>
>>> Numa is currently not supported for arm in xen.
>> 
>> This doesn't represent a valid reason for the code to be disabled,
>> the more that ARM will want to support NUMA sooner or later. A
>> valid reason would be if you'd have to introduce _a lot_ of code on
>> the ARM side in order to make this build - if that's the case, please
>> say so in the description, as from an architectural pov the absence
>> of the respective ACPI tables should be no issue at all.
> 
> The acpi/numa.c is calling a lot of arch specific function implemented
> in (arch/x86/srat.c). The code in acpi/numa.c is very x86 related (such
> as x2apic).
> 
> I think disable the compilation is preferable for now given that there
> is no board for testing the changes.

Or, as said in reply to patch 2, stubbing out the missing pieces in
ARM code. As said there - let's not make more spaghetti of common
code than it already is.

Jan

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

[Julien Grall]

On 20/05/15 16:41, Jan Beulich wrote:
>>>> On 20.05.15 at 17:21, <julien.grall@citrix.com> wrote:
>> On 20/05/15 16:07, Jan Beulich wrote:
>>>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>>>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>>>
>>>> Numa is currently not supported for arm in xen.
>>>
>>> This doesn't represent a valid reason for the code to be disabled,
>>> the more that ARM will want to support NUMA sooner or later. A
>>> valid reason would be if you'd have to introduce _a lot_ of code on
>>> the ARM side in order to make this build - if that's the case, please
>>> say so in the description, as from an architectural pov the absence
>>> of the respective ACPI tables should be no issue at all.
>>
>> The acpi/numa.c is calling a lot of arch specific function implemented
>> in (arch/x86/srat.c). The code in acpi/numa.c is very x86 related (such
>> as x2apic).
>>
>> I think disable the compilation is preferable for now given that there
>> is no board for testing the changes.
> 
> Or, as said in reply to patch 2, stubbing out the missing pieces in
> ARM code. As said there - let's not make more spaghetti of common
> code than it already is.

That would mean we will build a code that won't be use on ARM until we
decide to implement NUMA. This is because the main function
acpi_numa_init is not called and should not be called until someone
figure out this is valid on ARM.

What about defining a new define HAVE_NUMA?

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 20.05.15 at 17:49, <julien.grall@citrix.com> wrote:
> What about defining a new define HAVE_NUMA?

That might be an acceptable compromise.

Jan

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

[Parth Dixit]

+shannon

On 20 May 2015 at 22:01, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.05.15 at 17:49, <julien.grall@citrix.com> wrote:
>> What about defining a new define HAVE_NUMA?
>
> That might be an acceptable compromise.
>
> Jan
>

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

[Julien Grall]

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?

Archives also exists for Xen devel, and it's even possible to  download 
them in order to answer to the mail....

Regards,

-- 
Julien Grall

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

[Parth Dixit]

On 5 July 2015 at 23:09, Julien Grall <julien.grall@citrix.com> 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

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

[Jan Beulich]

>>> On 05.07.15 at 19:39, <julien.grall@citrix.com> wrote:
> 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?

Seconded. Considering this I simply deleted all the mails by you on that
thread and on that day. Should there have been anything that I indeed
needed to look at, please point this out specifically.

Jan

[PATCH v2 02/41] arm/acpi: Build pmstat for x86 only

[Parth Dixit]

Pmstat is currently not supported for arm in xen.
Configure and build pmstat for x86 architecture only.

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 xen/common/sysctl.c       | 2 ++
 xen/drivers/acpi/Makefile | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 601dd09..96d06cf 100644
--- 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);
@@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
             copyback = 1;
         break;
 #endif
+#endif
 
     case XEN_SYSCTL_page_offline_op:
     {
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 7294b5a..009fe5a 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,7 @@ subdir-$(x86) += apei
 obj-bin-y += tables.init.o
 obj-$(x86) += numa.o
 obj-y += osl.o
-obj-y += pmstat.o
+obj-$(x86) += pmstat.o
 
 obj-$(x86) += hwregs.o
 obj-$(x86) += reboot.o
-- 
1.9.1

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

[Julien Grall]

Hi Parth,

On 17/05/15 21:03, Parth Dixit wrote:
> Pmstat is currently not supported for arm in xen.
> Configure and build pmstat for x86 architecture only.
> 
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  xen/common/sysctl.c       | 2 ++
>  xen/drivers/acpi/Makefile | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index 601dd09..96d06cf 100644
> --- 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

pmstat seems to be tight with cpufreq, so I would use HAS_CPUFREQ.

>  #ifdef HAS_ACPI

And combine the two #ifdef.

>      case XEN_SYSCTL_get_pmstat:
>          ret = do_get_pm_info(&op->u.get_pmstat);
> @@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>              copyback = 1;
>          break;
>  #endif
> +#endif
>  
>      case XEN_SYSCTL_page_offline_op:
>      {
> diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
> index 7294b5a..009fe5a 100644
> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -5,7 +5,7 @@ subdir-$(x86) += apei
>  obj-bin-y += tables.init.o
>  obj-$(x86) += numa.o
>  obj-y += osl.o
> -obj-y += pmstat.o
> +obj-$(x86) += pmstat.o

obj-$(HAS_CPUFREQ)

>  
>  obj-$(x86) += hwregs.o
>  obj-$(x86) += reboot.o
> 

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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.

> --- 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

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 965 bytes --]

On 20 May 2015 at 20:42, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 1720 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 11:40, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 20 May 2015 at 20:42, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
>>
>

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

[Parth Dixit]

add macros to emulate x86 style ports for arm.
This avoids modification in common code for acpi.

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <asm/system.h>
 #include <asm/byteorder.h>
 
 /*
@@ -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

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

[Julien Grall]

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

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

[Parth Dixit]

+shannon

On 18 May 2015 at 18:33, Julien Grall <julien.grall@citrix.com> 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

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

[Parth Dixit]

add architecture specific definitions and calls
required for acpi in new header file

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 0000000..f771056
--- /dev/null
+++ b/xen/include/asm-arm/acpi.h
@@ -0,0 +1,38 @@
+/*
+ *  Copyright (C) 2014, Naresh Bhat <naresh.bhat@linaro.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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 <xen/init.h>
+
+#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

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

[Julien Grall]

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 <xen/init.h>
> +
> +#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.

> +#endif /*_ASM_ARM_ACPI_H*/
> 

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 908 bytes --]

On 18 May 2015 at 18:42, Julien Grall <julien.grall.oss@gmail.com> 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 <xen/init.h>
> > +
> > +#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
>

[-- Attachment #1.2: Type: text/html, Size: 1588 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 11:29, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 18 May 2015 at 18:42, Julien Grall <julien.grall.oss@gmail.com> 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 <xen/init.h>
>> > +
>> > +#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
>
>

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

[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 <parth.dixit@linaro.org>
---
 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 0000000..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 0000000..650beed
--- /dev/null
+++ b/xen/arch/arm/acpi/lib.c
@@ -0,0 +1,8 @@
+#include <xen/acpi.h>
+#include <asm/mm.h>
+
+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

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

[Julien Grall]

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 0000000..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 0000000..650beed
> --- /dev/null
> +++ b/xen/arch/arm/acpi/lib.c
> @@ -0,0 +1,8 @@
> +#include <xen/acpi.h>
> +#include <asm/mm.h>
> +
> +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...

>  /*
>   * 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

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

[Jan Beulich]

>>> On 18.05.15 at 15:26, <julien.grall@citrix.com> wrote:
> On 17/05/15 21:03, Parth Dixit wrote:
>> --- /dev/null
>> +++ b/xen/arch/arm/acpi/lib.c
>> @@ -0,0 +1,8 @@
>> +#include <xen/acpi.h>
>> +#include <asm/mm.h>
>> +
>> +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.

+1

> 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.

In which Linux version did you see this to be the case? Certainly
not 4.1-rc or anything recent... What I'm trying to get at is that
we should please be very careful with deviating from the ACPI CA
derived naming as well as with what is to live in os.c.

Jan

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

[Julien Grall]

On 18/05/15 15:01, Jan Beulich wrote:
>>>> On 18.05.15 at 15:26, <julien.grall@citrix.com> wrote:
>> On 17/05/15 21:03, Parth Dixit wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/arm/acpi/lib.c
>>> @@ -0,0 +1,8 @@
>>> +#include <xen/acpi.h>
>>> +#include <asm/mm.h>
>>> +
>>> +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.
> 
> +1
> 
>> 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.
> 
> In which Linux version did you see this to be the case? Certainly
> not 4.1-rc or anything recent... What I'm trying to get at is that
> we should please be very careful with deviating from the ACPI CA
> derived naming as well as with what is to live in os.c.

Sorry, I had in mind an older version of the ACPI series for Linux. I
forgot to check what was really done.

Although, acpi_os_map_iomem is also part of the ACPI CA. Would a
function arch_acpi_os_map_memory suit for you?

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 18.05.15 at 16:20, <julien.grall@citrix.com> wrote:
> Although, acpi_os_map_iomem is also part of the ACPI CA. Would a
> function arch_acpi_os_map_memory suit for you?

Only if we - other than Linux - really need this to be arch dependent.

Jan

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

[Julien Grall]

On 18/05/15 15:32, Jan Beulich wrote:
>>>> On 18.05.15 at 16:20, <julien.grall@citrix.com> wrote:
>> Although, acpi_os_map_iomem is also part of the ACPI CA. Would a
>> function arch_acpi_os_map_memory suit for you?
> 
> Only if we - other than Linux - really need this to be arch dependent.

The current implementation of acpi_os_map_iomem is not valid on ARM:
the first MB is not always mapped and we already have mapped the table
if it lives in RAM.

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 3058 bytes --]

On 18 May 2015 at 18:56, Julien Grall <julien.grall@citrix.com> 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 0000000..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 0000000..650beed
> > --- /dev/null
> > +++ b/xen/arch/arm/acpi/lib.c
> > @@ -0,0 +1,8 @@
> > +#include <xen/acpi.h>
> > +#include <asm/mm.h>
> > +
> > +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
>

[-- Attachment #1.2: Type: text/html, Size: 4145 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Julien Grall]

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 0000000..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 0000000..650beed
>      > --- /dev/null
>      > +++ b/xen/arch/arm/acpi/lib.c
>      > @@ -0,0 +1,8 @@
>      > +#include <xen/acpi.h>
>      > +#include <asm/mm.h>
>      > +
>      > +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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 13:01, Julien Grall <julien.grall@citrix.com> 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 0000000..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 0000000..650beed
>>      > --- /dev/null
>>      > +++ b/xen/arch/arm/acpi/lib.c
>>      > @@ -0,0 +1,8 @@
>>      > +#include <xen/acpi.h>
>>      > +#include <asm/mm.h>
>>      > +
>>      > +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

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
> --- 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);
>  }

I think ioremap() (or maybe ioremap_cache()) should be used here,
and tweaked suitably on x86 if need be.

Jan

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

[Julien Grall]

On 20/05/15 17:03, Jan Beulich wrote:
>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>> --- 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);
>>  }
> 
> I think ioremap() (or maybe ioremap_cache()) should be used here,
> and tweaked suitably on x86 if need be.

ioremap_cache is most suitable for ARM.

ioremap (i.e ioremap_nocache) is mapping the region with device
attribute. Any unaligned access will result to a data abort.

Regards,

-- 
Julien Grall

[PATCH v2 06/41] arm/acpi : Add basic ACPI initialization

[Parth Dixit]

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 <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 0000000..8dc69d5
--- /dev/null
+++ b/xen/arch/arm/acpi/boot.c
@@ -0,0 +1,56 @@
+/*
+ *  ARM64 Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2014, Naresh Bhat <naresh.bhat@linaro.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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 <xen/init.h>
+#include <xen/acpi.h>
+
+#include <asm/acpi.h>
+
+/*
+ * 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.
+ */
+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();
+    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 <xen/pfn.h>
 #include <xen/vmap.h>
 #include <xen/libfdt/libfdt.h>
+#include <xen/acpi.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>
@@ -45,10 +46,12 @@
 #include <asm/procinfo.h>
 #include <asm/setup.h>
 #include <xsm/xsm.h>
+#include <asm/acpi.h>
 
 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 dtb_size)
     init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
                        pfn_to_paddr(boot_mfn_start));
 
-    end_boot_allocator();
 }
 #else /* CONFIG_ARM_64 */
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
@@ -680,7 +682,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     setup_frametable_mappings(ram_start, ram_end);
     max_page = PFN_DOWN(ram_end);
 
-    end_boot_allocator();
 }
 #endif
 
@@ -751,6 +752,14 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     setup_mm(fdt_paddr, fdt_size);
 
+    /*
+    * Parse the ACPI tables for possible boot-time configuration
+    */
+    if( !acpi_disabled )
+        acpi_boot_table_init();
+
+    end_boot_allocator();
+
     vm_init();
     dt_unflatten_host_device_tree();
 
-- 
1.9.1

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

[Julien Grall]

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 <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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 0000000..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 <naresh.bhat@linaro.org>

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 <xen/init.h>
> +#include <xen/acpi.h>
> +
> +#include <asm/acpi.h>
> +
> +/*
> + * 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.

> +    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 <xen/pfn.h>
>  #include <xen/vmap.h>
>  #include <xen/libfdt/libfdt.h>
> +#include <xen/acpi.h>
>  #include <asm/page.h>
>  #include <asm/current.h>
>  #include <asm/setup.h>
> @@ -45,10 +46,12 @@
>  #include <asm/procinfo.h>
>  #include <asm/setup.h>
>  #include <xsm/xsm.h>
> +#include <asm/acpi.h>
>  
>  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 dtb_size)
>      init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
>                         pfn_to_paddr(boot_mfn_start));
>  
> -    end_boot_allocator();
>  }
>  #else /* CONFIG_ARM_64 */
>  static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
> @@ -680,7 +682,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
>      setup_frametable_mappings(ram_start, ram_end);
>      max_page = PFN_DOWN(ram_end);
>  
> -    end_boot_allocator();

You need to explain in the commit message why this is necessary (see [1]).

Anybody who didn't follow/remember the thread will think this is wrong...

>  }
>  #endif
>  
> @@ -751,6 +752,14 @@ void __init start_xen(unsigned long boot_phys_offset,
>  
>      setup_mm(fdt_paddr, fdt_size);
>  
> +    /*
> +    * Parse the ACPI tables for possible boot-time configuration
> +    */

Coding style.

/*
 * Foo
 * bar
 */

Although the comment is fitting in a single line so
/* foo bar */

Bu

> +    if( !acpi_disabled )

The if is not necessary.

> +        acpi_boot_table_init();
> +
> +    end_boot_allocator();
> +
>      vm_init();
>      dt_unflatten_host_device_tree();
>  
> 

Regards,

[1]
http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01152.html

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 5934 bytes --]

On 18 May 2015 at 19:41, Julien Grall <julien.grall@citrix.com> 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 <naresh.bhat@linaro.org>
> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > ---
> >  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 0000000..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 <naresh.bhat@linaro.org>
>
> 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 <xen/init.h>
> > +#include <xen/acpi.h>
> > +
> > +#include <asm/acpi.h>
> > +
> > +/*
> > + * 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 <xen/pfn.h>
> >  #include <xen/vmap.h>
> >  #include <xen/libfdt/libfdt.h>
> > +#include <xen/acpi.h>
> >  #include <asm/page.h>
> >  #include <asm/current.h>
> >  #include <asm/setup.h>
> > @@ -45,10 +46,12 @@
> >  #include <asm/procinfo.h>
> >  #include <asm/setup.h>
> >  #include <xsm/xsm.h>
> > +#include <asm/acpi.h>
> >
> >  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 dtb_size)
> >      init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
> >                         pfn_to_paddr(boot_mfn_start));
> >
> > -    end_boot_allocator();
> >  }
> >  #else /* CONFIG_ARM_64 */
> >  static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
> > @@ -680,7 +682,6 @@ static void __init setup_mm(unsigned long dtb_paddr,
> size_t dtb_size)
> >      setup_frametable_mappings(ram_start, ram_end);
> >      max_page = PFN_DOWN(ram_end);
> >
> > -    end_boot_allocator();
>
> You need to explain in the commit message why this is necessary (see [1]).
>
> Anybody who didn't follow/remember the thread will think this is wrong...
>
> ok, will take care in next patchset.

> >  }
> >  #endif
> >
> > @@ -751,6 +752,14 @@ void __init start_xen(unsigned long
> boot_phys_offset,
> >
> >      setup_mm(fdt_paddr, fdt_size);
> >
> > +    /*
> > +    * Parse the ACPI tables for possible boot-time configuration
> > +    */
>
> Coding style.
>
> /*
>  * Foo
>  * bar
>  */
>
> Although the comment is fitting in a single line so
> /* foo bar */
>
> Bu
>
> > +    if( !acpi_disabled )
>
> The if is not necessary.
>
> > +        acpi_boot_table_init();
> > +
> > +    end_boot_allocator();
> > +
> >      vm_init();
> >      dt_unflatten_host_device_tree();
> >
> >
>
> Regards,
>
> [1]
> http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01152.html
>
> --
> Julien Grall
>

[-- Attachment #1.2: Type: text/html, Size: 8286 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 11:32, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 18 May 2015 at 19:41, Julien Grall <julien.grall@citrix.com> 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 <naresh.bhat@linaro.org>
>> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> > ---
>> >  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 0000000..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 <naresh.bhat@linaro.org>
>>
>> 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 <xen/init.h>
>> > +#include <xen/acpi.h>
>> > +
>> > +#include <asm/acpi.h>
>> > +
>> > +/*
>> > + * 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 <xen/pfn.h>
>> >  #include <xen/vmap.h>
>> >  #include <xen/libfdt/libfdt.h>
>> > +#include <xen/acpi.h>
>> >  #include <asm/page.h>
>> >  #include <asm/current.h>
>> >  #include <asm/setup.h>
>> > @@ -45,10 +46,12 @@
>> >  #include <asm/procinfo.h>
>> >  #include <asm/setup.h>
>> >  #include <xsm/xsm.h>
>> > +#include <asm/acpi.h>
>> >
>> >  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 dtb_size)
>> >      init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
>> >                         pfn_to_paddr(boot_mfn_start));
>> >
>> > -    end_boot_allocator();
>> >  }
>> >  #else /* CONFIG_ARM_64 */
>> >  static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
>> > @@ -680,7 +682,6 @@ static void __init setup_mm(unsigned long dtb_paddr,
>> > size_t dtb_size)
>> >      setup_frametable_mappings(ram_start, ram_end);
>> >      max_page = PFN_DOWN(ram_end);
>> >
>> > -    end_boot_allocator();
>>
>> You need to explain in the commit message why this is necessary (see [1]).
>>
>> Anybody who didn't follow/remember the thread will think this is wrong...
>>
> ok, will take care in next patchset.
>>
>> >  }
>> >  #endif
>> >
>> > @@ -751,6 +752,14 @@ void __init start_xen(unsigned long
>> > boot_phys_offset,
>> >
>> >      setup_mm(fdt_paddr, fdt_size);
>> >
>> > +    /*
>> > +    * Parse the ACPI tables for possible boot-time configuration
>> > +    */
>>
>> Coding style.
>>
>> /*
>>  * Foo
>>  * bar
>>  */
>>
>> Although the comment is fitting in a single line so
>> /* foo bar */
>>
>> Bu
>>
>> > +    if( !acpi_disabled )
>>
>> The if is not necessary.
>>
>> > +        acpi_boot_table_init();
>> > +
>> > +    end_boot_allocator();
>> > +
>> >      vm_init();
>> >      dt_unflatten_host_device_tree();
>> >
>> >
>>
>> Regards,
>>
>> [1]
>> http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01152.html
>>
>> --
>> Julien Grall
>
>

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

[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 <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
 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

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

[Julien Grall]

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 <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
>  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)?

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 3555 bytes --]

On 18 May 2015 at 19:59, Julien Grall <julien.grall@citrix.com> 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 <hanjun.guo@linaro.org>
> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> > ---
> >  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
>

[-- Attachment #1.2: Type: text/html, Size: 4712 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 11:33, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 18 May 2015 at 19:59, Julien Grall <julien.grall@citrix.com> 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 <hanjun.guo@linaro.org>
>> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> > ---
>> >  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
>
>

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

[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 <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <xen/init.h>
 #include <xen/acpi.h>
+#include <xen/errno.h>
+#include <acpi/actables.h>
+#include <xen/mm.h>
 
 #include <asm/acpi.h>
 
+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

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

[Julien Grall]

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 <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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 <xen/init.h>
>  #include <xen/acpi.h>
> +#include <xen/errno.h>
> +#include <acpi/actables.h>
> +#include <xen/mm.h>
>  
>  #include <asm/acpi.h>
>  
> +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.

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/arm/acpi/lib.c
> @@ -6,3 +6,14 @@ acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>  {
>      return __va(phys);
>  }

missing blank line

> +/* 1 to indicate PSCI 0.2+ is implemented */
> +inline bool_t acpi_psci_present(void)

inline is not necessary. Although, I would move the function in the
header because it's very simple.

> +{
> +    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)

Ditto.

> +{
> +    return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> +}

Regards,

-- 
-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 5160 bytes --]

On 18 May 2015 at 20:28, Julien Grall <julien.grall@citrix.com> 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 <hanjun.guo@linaro.org>
> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > ---
> >  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 <xen/init.h>
> >  #include <xen/acpi.h>
> > +#include <xen/errno.h>
> > +#include <acpi/actables.h>
> > +#include <xen/mm.h>
> >
> >  #include <asm/acpi.h>
> >
> > +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/arm/acpi/lib.c
> > @@ -6,3 +6,14 @@ acpi_os_map_iomem(acpi_physical_address phys, acpi_size
> size)
> >  {
> >      return __va(phys);
> >  }
>
> missing blank line
>
> > +/* 1 to indicate PSCI 0.2+ is implemented */
> > +inline bool_t acpi_psci_present(void)
>
> inline is not necessary. Although, I would move the function in the
> header because it's very simple.
>
> > +{
> > +    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)
>
> Ditto.
>
> > +{
> > +    return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> > +}
>
> Regards,
>
> --
> --
> Julien Grall
>

[-- Attachment #1.2: Type: text/html, Size: 6984 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 11:35, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 18 May 2015 at 20:28, Julien Grall <julien.grall@citrix.com> 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 <hanjun.guo@linaro.org>
>> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> > ---
>> >  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 <xen/init.h>
>> >  #include <xen/acpi.h>
>> > +#include <xen/errno.h>
>> > +#include <acpi/actables.h>
>> > +#include <xen/mm.h>
>> >
>> >  #include <asm/acpi.h>
>> >
>> > +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/arm/acpi/lib.c
>> > @@ -6,3 +6,14 @@ acpi_os_map_iomem(acpi_physical_address phys, acpi_size
>> > size)
>> >  {
>> >      return __va(phys);
>> >  }
>>
>> missing blank line
>>
>> > +/* 1 to indicate PSCI 0.2+ is implemented */
>> > +inline bool_t acpi_psci_present(void)
>>
>> inline is not necessary. Although, I would move the function in the
>> header because it's very simple.
>>
>> > +{
>> > +    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)
>>
>> Ditto.
>>
>> > +{
>> > +    return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
>> > +}
>>
>> Regards,
>>
>> --
>> --
>> Julien Grall
>
>

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

[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 <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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

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

[Parth Dixit]

+shannon

On 18 May 2015 at 01:33, Parth Dixit <parth.dixit@linaro.org> 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 <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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
>

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

[Parth Dixit]

From: Naresh Bhat <naresh.bhat@linaro.org>

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

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
 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

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

[Julien Grall]

Hi Parth,

On 17/05/15 21:03, Parth Dixit wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
> 
> When MADT is parsed, print GIC information to make the boot
> log look pretty.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
>  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

> +        }
> +        break;
> +
>  	default:
>  		printk(KERN_WARNING PREFIX
>  		       "Found unsupported MADT entry (type = %#x)\n",
> 

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 3064 bytes --]

On 18 May 2015 at 20:36, Julien Grall <julien.grall@citrix.com> wrote:

> Hi Parth,
>
> On 17/05/15 21:03, Parth Dixit wrote:
> > From: Naresh Bhat <naresh.bhat@linaro.org>
> >
> > When MADT is parsed, print GIC information to make the boot
> > log look pretty.
> >
> > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> > ---
> >  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
>

[-- Attachment #1.2: Type: text/html, Size: 4866 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon


On 24 May 2015 at 11:39, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 18 May 2015 at 20:36, Julien Grall <julien.grall@citrix.com> wrote:
>>
>> Hi Parth,
>>
>> On 17/05/15 21:03, Parth Dixit wrote:
>> > From: Naresh Bhat <naresh.bhat@linaro.org>
>> >
>> > When MADT is parsed, print GIC information to make the boot
>> > log look pretty.
>> >
>> > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> > Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> > ---
>> >  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
>
>

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

[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 <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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_MODE            1
-#define ACPI_GTDT_INTERRUPT_POLARITY        2
+#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

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

[Julien Grall]

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 <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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?

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 1809 bytes --]

On 18 May 2015 at 20:41, Julien Grall <julien.grall@citrix.com> 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 <hanjun.guo@linaro.org>
> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > ---
> >  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
>

[-- Attachment #1.2: Type: text/html, Size: 2776 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 11:36, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 18 May 2015 at 20:41, Julien Grall <julien.grall@citrix.com> 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 <hanjun.guo@linaro.org>
>> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> > ---
>> >  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
>
>

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

[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 <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

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

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

[Parth Dixit]

+shannon

On 20 May 2015 at 21:13, Julien Grall <julien.grall@citrix.com> 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

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

[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 <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <xen/mm.h>
 
 #include <asm/acpi.h>
+#include <asm/smp.h>
+
+/* 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 <xen/vmap.h>
 #include <asm/io.h>
 #include <asm/psci.h>
+#include <asm/acpi.h>
 
 struct smp_enable_ops {
         int             (*prepare_cpu)(int);
@@ -94,9 +95,13 @@ static int __init dt_arch_cpu_init(int cpu, struct dt_device_node *dn)
     return 0;
 }
 
+/* acpi only supports psci at present */
 int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
 {
-    return dt_arch_cpu_init(cpu, dn);
+    if( acpi_disabled )
+        return dt_arch_cpu_init(cpu, dn);
+    else
+        return smp_psci_init(cpu);
 }
 
 int __init arch_cpu_up(int cpu)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 4066309..20040aa 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -22,6 +22,7 @@
 #include <xen/mm.h>
 #include <xen/smp.h>
 #include <asm/psci.h>
+#include <asm/acpi.h>
 
 uint32_t psci_ver;
 
@@ -74,6 +75,9 @@ int __init psci_init_0_1(void)
     int ret;
     const struct dt_device_node *psci;
 
+    if ( !acpi_disabled )
+        return -EINVAL;
+
     psci = dt_find_compatible_node(NULL, NULL, "arm,psci");
     if ( !psci )
         return -EOPNOTSUPP;
@@ -98,6 +102,9 @@ int __init psci_init_0_1(void)
 int __init psci_init_0_2(void)
 {
     int ret;
+
+    if( acpi_disabled )
+    {
     const struct dt_device_node *psci;
 
     psci = dt_find_compatible_node(NULL, NULL, "arm,psci-0.2");
@@ -107,6 +114,15 @@ int __init psci_init_0_2(void)
     ret = psci_is_smc_method(psci);
     if ( ret )
         return -EINVAL;
+    }
+    else
+    {
+        if( !acpi_psci_present() )
+            return -EOPNOTSUPP;
+
+        if ( acpi_psci_hvc_present() )
+            return -EINVAL;
+    }
 
     psci_ver = call_smc(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 90f9ef2..1385dbe 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -31,6 +31,7 @@
 #include <xen/console.h>
 #include <asm/gic.h>
 #include <asm/psci.h>
+#include <asm/acpi.h>
 
 cpumask_t cpu_online_map;
 cpumask_t cpu_present_map;
@@ -246,7 +247,11 @@ void __init smp_init_cpus(void)
         return;
     }
 
-    dt_smp_init_cpus();
+    if ( acpi_disabled )
+        dt_smp_init_cpus();
+    else
+        acpi_init_cpus();
+
 }
 
 int __init
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 4a6cb37..0845f14 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -35,9 +35,11 @@ extern bool_t acpi_disabled;
 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);
+void __init acpi_init_cpus(void);
 #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) { }
 #endif /* CONFIG_ACPI */
 
 /* Basic configuration for ACPI */
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index afe2dca..ee6a5ea 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -40,6 +40,10 @@
 #define ACPI_MADT_GET_POLARITY(inti)	ACPI_MADT_GET_(POLARITY, inti)
 #define ACPI_MADT_GET_TRIGGER(inti)	ACPI_MADT_GET_(TRIGGER, inti)
 
+#define BAD_MADT_ENTRY(entry, end) (                                        \
+                (!entry) || (unsigned long)entry + sizeof(*entry) > end ||  \
+                ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
+
 #ifdef CONFIG_ACPI_BOOT
 
 enum acpi_interrupt_id {
@@ -57,6 +61,7 @@ typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, co
 
 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

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -40,6 +40,10 @@
>  #define ACPI_MADT_GET_POLARITY(inti)	ACPI_MADT_GET_(POLARITY, inti)
>  #define ACPI_MADT_GET_TRIGGER(inti)	ACPI_MADT_GET_(TRIGGER, inti)
>  
> +#define BAD_MADT_ENTRY(entry, end) (                                        \
> +                (!entry) || (unsigned long)entry + sizeof(*entry) > end ||  \
> +                ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))

This shouldn't be added here without the original getting removed
from xen/arch/x86/acpi/boot.c. And the latest when moving this to
a global header it needs to be properly parenthesized.

Jan

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

[Julien Grall]

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 <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>

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 <xen/mm.h>
>  
>  #include <asm/acpi.h>
> +#include <asm/smp.h>
> +
> +/* 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 )
> +    {
> +        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++;

Missing new line.

> +    return enabled_cpus;
> +}
> +
> +static int __init
> +    acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> +            const unsigned long end)

The indentation looks wrong.

> +{
> +    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);

It would be cleaner if you pass directly processor to the function (as
Linux does).

> +
> +    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);

Wrong indentation.

> +
> +    if ( count < 0 )
> +    {
> +        printk("Error parsing GIC CPU interface entry\n");
> +        return;
> +    }

What about the case where count == 0?

> +
> +    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

All the changes within this file and arm/psci.c is not mentioned in the
commit message.

As it's related to this patch, it would be better to have a separate
patch for it.

> @@ -7,6 +7,7 @@
>  #include <xen/vmap.h>
>  #include <asm/io.h>
>  #include <asm/psci.h>
> +#include <asm/acpi.h>
>  
>  struct smp_enable_ops {
>          int             (*prepare_cpu)(int);
> @@ -94,9 +95,13 @@ static int __init dt_arch_cpu_init(int cpu, struct dt_device_node *dn)
>      return 0;
>  }
>  
> +/* acpi only supports psci at present */

This comment should be in the else part below.

>  int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
>  {
> -    return dt_arch_cpu_init(cpu, dn);
> +    if( acpi_disabled )
> +        return dt_arch_cpu_init(cpu, dn);
> +    else
> +        return smp_psci_init(cpu);
>  }
>  
>  int __init arch_cpu_up(int cpu)
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index 4066309..20040aa 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -22,6 +22,7 @@
>  #include <xen/mm.h>
>  #include <xen/smp.h>
>  #include <asm/psci.h>
> +#include <asm/acpi.h>
>  
>  uint32_t psci_ver;
>  
> @@ -74,6 +75,9 @@ int __init psci_init_0_1(void)
>      int ret;
>      const struct dt_device_node *psci;
>  
> +    if ( !acpi_disabled )
> +        return -EINVAL;
> +
>      psci = dt_find_compatible_node(NULL, NULL, "arm,psci");
>      if ( !psci )
>          return -EOPNOTSUPP;
> @@ -98,6 +102,9 @@ int __init psci_init_0_1(void)
>  int __init psci_init_0_2(void)
>  {
>      int ret;
> +
> +    if( acpi_disabled )
> +    {
>      const struct dt_device_node *psci;

The block within the if should be indented correctly. Although, why
didn't you refactor the code as you did on some other part?

>      psci = dt_find_compatible_node(NULL, NULL, "arm,psci-0.2");
> @@ -107,6 +114,15 @@ int __init psci_init_0_2(void)
>      ret = psci_is_smc_method(psci);
>      if ( ret )
>          return -EINVAL;
> +    }
> +    else
> +    {
> +        if( !acpi_psci_present() )
> +            return -EOPNOTSUPP;

This should be done in psci_init and not here.

> +
> +        if ( acpi_psci_hvc_present() )
> +            return -EINVAL;
> +    }
>  
>      psci_ver = call_smc(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
>  
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 90f9ef2..1385dbe 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -31,6 +31,7 @@
>  #include <xen/console.h>
>  #include <asm/gic.h>
>  #include <asm/psci.h>
> +#include <asm/acpi.h>
>  
>  cpumask_t cpu_online_map;
>  cpumask_t cpu_present_map;
> @@ -246,7 +247,11 @@ void __init smp_init_cpus(void)
>          return;
>      }
>  
> -    dt_smp_init_cpus();
> +    if ( acpi_disabled )
> +        dt_smp_init_cpus();
> +    else
> +        acpi_init_cpus();
> +
>  }
>  
>  int __init
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index 4a6cb37..0845f14 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -35,9 +35,11 @@ extern bool_t acpi_disabled;
>  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);
> +void __init acpi_init_cpus(void);
>  #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) { }
>  #endif /* CONFIG_ACPI */
>  
>  /* Basic configuration for ACPI */
> diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
> index afe2dca..ee6a5ea 100644
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -40,6 +40,10 @@
>  #define ACPI_MADT_GET_POLARITY(inti)	ACPI_MADT_GET_(POLARITY, inti)
>  #define ACPI_MADT_GET_TRIGGER(inti)	ACPI_MADT_GET_(TRIGGER, inti)
>  
> +#define BAD_MADT_ENTRY(entry, end) (                                        \
> +                (!entry) || (unsigned long)entry + sizeof(*entry) > end ||  \
> +                ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
> +
>  #ifdef CONFIG_ACPI_BOOT
>  
>  enum acpi_interrupt_id {
> @@ -57,6 +61,7 @@ typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, co
>  
>  void __iomem *
>  acpi_os_map_iomem(acpi_physical_address phys, acpi_size size);
> +

Spurious change

>  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);
> 


Regards,

-- 
Julien Grall

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

[Parth Dixit]

+shannon

On 20 May 2015 at 22:08, Julien Grall <julien.grall@citrix.com> 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 <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>
> 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 <xen/mm.h>
>>
>>  #include <asm/acpi.h>
>> +#include <asm/smp.h>
>> +
>> +/* 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 )
>> +    {
>> +        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++;
>
> Missing new line.
>
>> +    return enabled_cpus;
>> +}
>> +
>> +static int __init
>> +    acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
>> +            const unsigned long end)
>
> The indentation looks wrong.
>
>> +{
>> +    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);
>
> It would be cleaner if you pass directly processor to the function (as
> Linux does).
>
>> +
>> +    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);
>
> Wrong indentation.
>
>> +
>> +    if ( count < 0 )
>> +    {
>> +        printk("Error parsing GIC CPU interface entry\n");
>> +        return;
>> +    }
>
> What about the case where count == 0?
>
>> +
>> +    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
>
> All the changes within this file and arm/psci.c is not mentioned in the
> commit message.
>
> As it's related to this patch, it would be better to have a separate
> patch for it.
>
>> @@ -7,6 +7,7 @@
>>  #include <xen/vmap.h>
>>  #include <asm/io.h>
>>  #include <asm/psci.h>
>> +#include <asm/acpi.h>
>>
>>  struct smp_enable_ops {
>>          int             (*prepare_cpu)(int);
>> @@ -94,9 +95,13 @@ static int __init dt_arch_cpu_init(int cpu, struct dt_device_node *dn)
>>      return 0;
>>  }
>>
>> +/* acpi only supports psci at present */
>
> This comment should be in the else part below.
>
>>  int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
>>  {
>> -    return dt_arch_cpu_init(cpu, dn);
>> +    if( acpi_disabled )
>> +        return dt_arch_cpu_init(cpu, dn);
>> +    else
>> +        return smp_psci_init(cpu);
>>  }
>>
>>  int __init arch_cpu_up(int cpu)
>> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
>> index 4066309..20040aa 100644
>> --- a/xen/arch/arm/psci.c
>> +++ b/xen/arch/arm/psci.c
>> @@ -22,6 +22,7 @@
>>  #include <xen/mm.h>
>>  #include <xen/smp.h>
>>  #include <asm/psci.h>
>> +#include <asm/acpi.h>
>>
>>  uint32_t psci_ver;
>>
>> @@ -74,6 +75,9 @@ int __init psci_init_0_1(void)
>>      int ret;
>>      const struct dt_device_node *psci;
>>
>> +    if ( !acpi_disabled )
>> +        return -EINVAL;
>> +
>>      psci = dt_find_compatible_node(NULL, NULL, "arm,psci");
>>      if ( !psci )
>>          return -EOPNOTSUPP;
>> @@ -98,6 +102,9 @@ int __init psci_init_0_1(void)
>>  int __init psci_init_0_2(void)
>>  {
>>      int ret;
>> +
>> +    if( acpi_disabled )
>> +    {
>>      const struct dt_device_node *psci;
>
> The block within the if should be indented correctly. Although, why
> didn't you refactor the code as you did on some other part?
>
>>      psci = dt_find_compatible_node(NULL, NULL, "arm,psci-0.2");
>> @@ -107,6 +114,15 @@ int __init psci_init_0_2(void)
>>      ret = psci_is_smc_method(psci);
>>      if ( ret )
>>          return -EINVAL;
>> +    }
>> +    else
>> +    {
>> +        if( !acpi_psci_present() )
>> +            return -EOPNOTSUPP;
>
> This should be done in psci_init and not here.
>
>> +
>> +        if ( acpi_psci_hvc_present() )
>> +            return -EINVAL;
>> +    }
>>
>>      psci_ver = call_smc(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
>>
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index 90f9ef2..1385dbe 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -31,6 +31,7 @@
>>  #include <xen/console.h>
>>  #include <asm/gic.h>
>>  #include <asm/psci.h>
>> +#include <asm/acpi.h>
>>
>>  cpumask_t cpu_online_map;
>>  cpumask_t cpu_present_map;
>> @@ -246,7 +247,11 @@ void __init smp_init_cpus(void)
>>          return;
>>      }
>>
>> -    dt_smp_init_cpus();
>> +    if ( acpi_disabled )
>> +        dt_smp_init_cpus();
>> +    else
>> +        acpi_init_cpus();
>> +
>>  }
>>
>>  int __init
>> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
>> index 4a6cb37..0845f14 100644
>> --- a/xen/include/asm-arm/acpi.h
>> +++ b/xen/include/asm-arm/acpi.h
>> @@ -35,9 +35,11 @@ extern bool_t acpi_disabled;
>>  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);
>> +void __init acpi_init_cpus(void);
>>  #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) { }
>>  #endif /* CONFIG_ACPI */
>>
>>  /* Basic configuration for ACPI */
>> diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
>> index afe2dca..ee6a5ea 100644
>> --- a/xen/include/xen/acpi.h
>> +++ b/xen/include/xen/acpi.h
>> @@ -40,6 +40,10 @@
>>  #define ACPI_MADT_GET_POLARITY(inti) ACPI_MADT_GET_(POLARITY, inti)
>>  #define ACPI_MADT_GET_TRIGGER(inti)  ACPI_MADT_GET_(TRIGGER, inti)
>>
>> +#define BAD_MADT_ENTRY(entry, end) (                                        \
>> +                (!entry) || (unsigned long)entry + sizeof(*entry) > end ||  \
>> +                ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
>> +
>>  #ifdef CONFIG_ACPI_BOOT
>>
>>  enum acpi_interrupt_id {
>> @@ -57,6 +61,7 @@ typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, co
>>
>>  void __iomem *
>>  acpi_os_map_iomem(acpi_physical_address phys, acpi_size size);
>> +
>
> Spurious change
>
>>  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);
>>
>
>
> Regards,
>
> --
> Julien Grall

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

[Parth Dixit]

set edge/level type information for an interrupt

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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           0x00000000
+#define ACPI_IRQ_TYPE_EDGE_RISING    0x00000001
+#define ACPI_IRQ_TYPE_EDGE_FALLING   0x00000002
+#define ACPI_IRQ_TYPE_EDGE_BOTH                           \
+    (ACPI_IRQ_TYPE_EDGE_FALLING | ACPI_IRQ_TYPE_EDGE_RISING)
+#define ACPI_IRQ_TYPE_LEVEL_HIGH     0x00000004
+#define ACPI_IRQ_TYPE_LEVEL_LOW      0x00000008
+#define ACPI_IRQ_TYPE_LEVEL_MASK                          \
+    (ACPI_IRQ_TYPE_LEVEL_LOW | ACPI_IRQ_TYPE_LEVEL_HIGH)
+#define ACPI_IRQ_TYPE_SENSE_MASK     0x0000000f
+
+#define ACPI_IRQ_TYPE_INVALID        0x00000010
+
 #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

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

[Julien Grall]

Hi,

On 17/05/15 21:03, Parth Dixit wrote:
> set edge/level type information for an interrupt
> 
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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           0x00000000
> +#define ACPI_IRQ_TYPE_EDGE_RISING    0x00000001
> +#define ACPI_IRQ_TYPE_EDGE_FALLING   0x00000002
> +#define ACPI_IRQ_TYPE_EDGE_BOTH                           \
> +    (ACPI_IRQ_TYPE_EDGE_FALLING | ACPI_IRQ_TYPE_EDGE_RISING)
> +#define ACPI_IRQ_TYPE_LEVEL_HIGH     0x00000004
> +#define ACPI_IRQ_TYPE_LEVEL_LOW      0x00000008
> +#define ACPI_IRQ_TYPE_LEVEL_MASK                          \
> +    (ACPI_IRQ_TYPE_LEVEL_LOW | ACPI_IRQ_TYPE_LEVEL_HIGH)
> +#define ACPI_IRQ_TYPE_SENSE_MASK     0x0000000f
> +
> +#define ACPI_IRQ_TYPE_INVALID        0x00000010
> +

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

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

[Parth Dixit]

+shannon

On 20 May 2015 at 22:51, Julien Grall <julien.grall@citrix.com> wrote:
> Hi,
>
> On 17/05/15 21:03, Parth Dixit wrote:
>> set edge/level type information for an interrupt
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>>  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           0x00000000
>> +#define ACPI_IRQ_TYPE_EDGE_RISING    0x00000001
>> +#define ACPI_IRQ_TYPE_EDGE_FALLING   0x00000002
>> +#define ACPI_IRQ_TYPE_EDGE_BOTH                           \
>> +    (ACPI_IRQ_TYPE_EDGE_FALLING | ACPI_IRQ_TYPE_EDGE_RISING)
>> +#define ACPI_IRQ_TYPE_LEVEL_HIGH     0x00000004
>> +#define ACPI_IRQ_TYPE_LEVEL_LOW      0x00000008
>> +#define ACPI_IRQ_TYPE_LEVEL_MASK                          \
>> +    (ACPI_IRQ_TYPE_LEVEL_LOW | ACPI_IRQ_TYPE_LEVEL_HIGH)
>> +#define ACPI_IRQ_TYPE_SENSE_MASK     0x0000000f
>> +
>> +#define ACPI_IRQ_TYPE_INVALID        0x00000010
>> +
>
> 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

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

[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 <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <asm/acpi.h>
 #include <asm/smp.h>
+#include <asm/irq.h>
+#include <asm/time.h>
 
 /* 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 **)&gtdt);
+
+    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 <xen/time.h>
 #include <xen/sched.h>
 #include <xen/event.h>
+#include <xen/acpi.h>
 #include <asm/system.h>
 #include <asm/time.h>
 #include <asm/gic.h>
@@ -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++ )
+        {
+            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;
+        }
     }
 
     /* Check that this CPU supports the Generic Timer interface */
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 1767143..482cc5b 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -36,10 +36,12 @@ 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);
 void __init acpi_init_cpus(void);
+void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[]);
 #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[]){ }
 #endif /* CONFIG_ACPI */
 
 /* Basic configuration for ACPI */
-- 
1.9.1

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

[Julien Grall]

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 <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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 <asm/acpi.h>
>  #include <asm/smp.h>
> +#include <asm/irq.h>
> +#include <asm/time.h>
>  
>  /* 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 **)&gtdt);
> +
> +    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 */. Maybe explaining that the table is re-used.

Furthermore, are you sure that the ACPI table will always be in R/W
memory? If not, we should duplicate the table and update the field.

> +    }
> +}
> +
>  /*
>   * 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 <xen/time.h>
>  #include <xen/sched.h>
>  #include <xen/event.h>
> +#include <xen/acpi.h>
>  #include <asm/system.h>
>  #include <asm/time.h>
>  #include <asm/gic.h>
> @@ -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 )
> +}
> +
> +
> +

Only one blank line is enough.

> +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) )

A such check calls for more refactoring...

>          cpu_khz = rate / 1000;
>      else
>          cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;

Duplicating this line wouldn't have been too bad compare to the check.

> @@ -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++ )
> +        {
> +            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;
> +        }

Another helper for this device tree code?

>      }
>  
>      /* Check that this CPU supports the Generic Timer interface */
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index 1767143..482cc5b 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -36,10 +36,12 @@ 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);
>  void __init acpi_init_cpus(void);
> +void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[]);
>  #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[]){ }
>  #endif /* CONFIG_ACPI */
>  
>  /* Basic configuration for ACPI */
> 

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 8469 bytes --]

On 20 May 2015 at 23:33, Julien Grall <julien.grall@citrix.com> 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 <naresh.bhat@linaro.org>
> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > ---
> >  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 <asm/acpi.h>
> >  #include <asm/smp.h>
> > +#include <asm/irq.h>
> > +#include <asm/time.h>
> >
> >  /* 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
> **)&gtdt);
> > +
> > +    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 */. Maybe explaining that the table is re-used.
>
> Furthermore, are you sure that the ACPI table will always be in R/W
> memory? If not, we should duplicate the table and update the field.
>
> > +    }
> > +}
> > +
> >  /*
> >   * 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 <xen/time.h>
> >  #include <xen/sched.h>
> >  #include <xen/event.h>
> > +#include <xen/acpi.h>
> >  #include <asm/system.h>
> >  #include <asm/time.h>
> >  #include <asm/gic.h>
> > @@ -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 )
> > +}
> > +
> > +
> > +
>
> Only one blank line is enough.
>
> > +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) )
>
> A such check calls for more refactoring...
>
> >          cpu_khz = rate / 1000;
> >      else
> >          cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
>
> Duplicating this line wouldn't have been too bad compare to the check.
>
> > @@ -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++ )
> > +        {
> > +            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;
> > +        }
>
> Another helper for this device tree code?
>
> >      }
> >
> >      /* Check that this CPU supports the Generic Timer interface */
> > diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> > index 1767143..482cc5b 100644
> > --- a/xen/include/asm-arm/acpi.h
> > +++ b/xen/include/asm-arm/acpi.h
> > @@ -36,10 +36,12 @@ 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);
> >  void __init acpi_init_cpus(void);
> > +void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[]);
> >  #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[]){ }
> >  #endif /* CONFIG_ACPI */
> >
> >  /* Basic configuration for ACPI */
> >
>
> sure, will take care in next patchset.

> Regards,
>
> --
> Julien Grall
>

[-- Attachment #1.2: Type: text/html, Size: 11174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 12:30, Parth Dixit <parth.dixit@linaro.org> wrote:
>
>
> On 20 May 2015 at 23:33, Julien Grall <julien.grall@citrix.com> 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 <naresh.bhat@linaro.org>
>> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> > ---
>> >  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 <asm/acpi.h>
>> >  #include <asm/smp.h>
>> > +#include <asm/irq.h>
>> > +#include <asm/time.h>
>> >
>> >  /* 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
>> > **)&gtdt);
>> > +
>> > +    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 */. Maybe explaining that the table is re-used.
>>
>> Furthermore, are you sure that the ACPI table will always be in R/W
>> memory? If not, we should duplicate the table and update the field.
>>
>> > +    }
>> > +}
>> > +
>> >  /*
>> >   * 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 <xen/time.h>
>> >  #include <xen/sched.h>
>> >  #include <xen/event.h>
>> > +#include <xen/acpi.h>
>> >  #include <asm/system.h>
>> >  #include <asm/time.h>
>> >  #include <asm/gic.h>
>> > @@ -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 )
>> > +}
>> > +
>> > +
>> > +
>>
>> Only one blank line is enough.
>>
>> > +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) )
>>
>> A such check calls for more refactoring...
>>
>> >          cpu_khz = rate / 1000;
>> >      else
>> >          cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
>>
>> Duplicating this line wouldn't have been too bad compare to the check.
>>
>> > @@ -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++ )
>> > +        {
>> > +            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;
>> > +        }
>>
>> Another helper for this device tree code?
>>
>> >      }
>> >
>> >      /* Check that this CPU supports the Generic Timer interface */
>> > diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
>> > index 1767143..482cc5b 100644
>> > --- a/xen/include/asm-arm/acpi.h
>> > +++ b/xen/include/asm-arm/acpi.h
>> > @@ -36,10 +36,12 @@ 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);
>> >  void __init acpi_init_cpus(void);
>> > +void __init acpi_preinit_xen_time(unsigned int generic_timer_irq[]);
>> >  #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[]){ }
>> >  #endif /* CONFIG_ACPI */
>> >
>> >  /* Basic configuration for ACPI */
>> >
>>
> sure, will take care in next patchset.
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>

[PATCH v2 16/41] acpi : Introduce acpi_parse_entries

[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 <Naresh.Bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
you do here (and elsewhere).

Jan

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 768 bytes --]

On 20 May 2015 at 21:43, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 1706 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Jan Beulich]

>>> On 21.05.15 at 11:14, <parth.dixit@linaro.org> wrote:
> On 20 May 2015 at 21:43, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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

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

[Parth Dixit]

+shannon

On 21 May 2015 at 14:50, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 21.05.15 at 11:14, <parth.dixit@linaro.org> wrote:
>> On 20 May 2015 at 21:43, Jan Beulich <JBeulich@suse.com> wrote:
>>
>>> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
>

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

[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 <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

Hi Parth,

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

Please explain why you don't refactor neither gic-hip04 and gic-v3.

> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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)

static init __init

> +{
> +     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)

This line is too long now.

>  {
>      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)

This function is not exported, so it should be static.

>  {
>      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)
>  {
> 

Regards,


-- 
Julien Grall

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>  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

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

[Parth Dixit]

+shannon

On 21 May 2015 at 17:52, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
>> ---
>>  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

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

[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 <parth.dixit@linaro.org>
---
 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 <xen/lib.h>
 
 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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>  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 <xen/lib.h>
>  
>  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.

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 3947 bytes --]

On 21 May 2015 at 16:49, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
> > ---
> >  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 <xen/lib.h>
> >
> >  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
>

[-- Attachment #1.2: Type: text/html, Size: 5434 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Julien Grall]

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.

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

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

[Parth Dixit]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

On 24 May 2015 at 13:10, Julien Grall <julien.grall@citrix.com> 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

[-- Attachment #2: Linaro Mail - [PATCH RFC 17_35] pl011_ Initialize serial from ACPI SPCR table.pdf --]
[-- Type: application/pdf, Size: 30471 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

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

[Julien Grall]

Hi Parth,

On 25/05/2015 07:58, Parth Dixit wrote:
> On 24 May 2015 at 13:10, Julien Grall <julien.grall@citrix.com> 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...

Also, that something useful to add in the notes of the patch (after ---).

Regards,

-- 
Julien Grall

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

[Parth Dixit]

On 25 May 2015 at 15:30, Julien Grall <julien.grall@citrix.com> wrote:
> Hi Parth,
>
> On 25/05/2015 07:58, Parth Dixit wrote:
>>
>> On 24 May 2015 at 13:10, Julien Grall <julien.grall@citrix.com> 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

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

[Parth Dixit]

+shannon

On 25 May 2015 at 17:08, Parth Dixit <parth.dixit@linaro.org> wrote:
> On 25 May 2015 at 15:30, Julien Grall <julien.grall@citrix.com> wrote:
>> Hi Parth,
>>
>> On 25/05/2015 07:58, Parth Dixit wrote:
>>>
>>> On 24 May 2015 at 13:10, Julien Grall <julien.grall@citrix.com> 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

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

[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 <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <xen/list.h>
 #include <xen/device_tree.h>
 #include <xen/libfdt/libfdt.h>
+#include <xen/acpi.h>
+#include <acpi/actables.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/platform.h>
@@ -35,6 +37,7 @@
 
 #include <asm/io.h>
 #include <asm/gic.h>
+#include <asm/acpi.h>
 
 /*
  * 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_gicv2_init();
 
     /* TODO: Add check on distributor, cpu size */
 
@@ -790,7 +906,21 @@ DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
         .dt_match = gicv2_dt_match,
         .init = dt_gicv2_preinit,
 DT_DEVICE_END
+#ifdef CONFIG_ACPI
+/* Set up the GIC */
+static int __init acpi_gicv2_preinit(const void *data)
+{
+    gicv2_info.hw_version = GIC_V2;
+    register_gic_ops(&gicv2_ops);
+
+    return 0;
+}
 
+ACPI_DEVICE_START(agicv2, "GICv2", DEVICE_GIC)
+        .class_type = GIC_V2,
+        .init = acpi_gicv2_preinit,
+ACPI_DEVICE_END
+#endif
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 701c306..e33bfd7 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -27,6 +27,7 @@
 #include <xen/softirq.h>
 #include <xen/list.h>
 #include <xen/device_tree.h>
+#include <xen/acpi.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/platform.h>
@@ -34,6 +35,7 @@
 #include <asm/io.h>
 #include <asm/gic.h>
 #include <asm/vgic.h>
+#include <asm/acpi.h>
 
 static void gic_restore_pending_irqs(struct vcpu *v);
 
@@ -261,9 +263,23 @@ void __init dt_gic_preinit(void)
     dt_device_set_used_by(node, DOMID_XEN);
 }
 
+static void __init acpi_gic_init(void)
+{
+    int rc;
+
+    /* NOTE: Only one GIC is supported */
+    /* hardcode to gic v2 for now */
+    rc = acpi_device_init(DEVICE_GIC, NULL, GIC_V2);
+    if ( rc )
+        panic("Unable to find compatible GIC in the ACPI table");
+}
+
 void __init gic_preinit(void)
 {
-    dt_gic_preinit();
+    if( acpi_disabled )
+        dt_gic_preinit();
+    else
+        acpi_gic_init();
 }
 
 /* Set up the GIC */
diff --git a/xen/drivers/char/arm-uart.c b/xen/drivers/char/arm-uart.c
new file mode 100644
index 0000000..2603508
--- /dev/null
+++ b/xen/drivers/char/arm-uart.c
@@ -0,0 +1,136 @@
+/*
+ * xen/drivers/char/dt-uart.c
+ *
+ * Generic uart retrieved via the device tree
+ *
+ * Julien Grall <julien.grall@linaro.org>
+ * 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 <asm/device.h>
+#include <asm/types.h>
+#include <xen/console.h>
+#include <xen/device_tree.h>
+#include <xen/serial.h>
+#include <xen/errno.h>
+#include <xen/acpi.h>
+
+/*
+ * 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);
+
+static 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);
+}
+
+static void __init acpi_uart_init(void)
+{
+#ifdef CONFIG_ACPI
+    struct acpi_table_spcr *spcr=NULL;
+    int ret;
+
+    acpi_get_table(ACPI_SIG_SPCR, 0,(struct acpi_table_header **)&spcr);
+
+    if ( spcr == NULL )
+        printk("Unable to get spcr table\n");
+    else
+    {
+        ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type);
+
+        if ( ret )
+            printk("Unable to initialize acpi uart: %d\n", ret);
+    }
+#endif
+}
+
+void __init uart_init(void)
+{
+    if ( acpi_disabled )
+        dt_uart_init();
+    else
+        acpi_uart_init();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1

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

[Julien Grall]

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 <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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 <xen/list.h>
>  #include <xen/device_tree.h>
>  #include <xen/libfdt/libfdt.h>
> +#include <xen/acpi.h>
> +#include <acpi/actables.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  #include <asm/platform.h>
> @@ -35,6 +37,7 @@
>  
>  #include <asm/io.h>
>  #include <asm/gic.h>
> +#include <asm/acpi.h>
>  
>  /*
>   * 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 would rename it to count.

> +
> +    status = acpi_get_table(ACPI_SIG_MADT, 0, &table);

For a generic ACPI device code it would make sense to pass the ACPI
table in parameter as you will likely have to retrieve the same table
within the same class of device (see Serial too).

> +
> +    if ( ACPI_FAILURE(status) )
> +    {

Wrong indentation within the block.

> +              const char *msg = acpi_format_exception(status);

Missing blank line

> +              printk("\nFailed to get MADT table, %s\n", msg);

The first "\n" is not necessary.

> +              return 1;

Please return a meaningful error code.

> +    }
> +
> +    /* 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);

Wrong indentation

> +    if ( res < 0 )	

0 means the no GICC which should be throwing an error too. I would
replace the check by

res <= 0

> +    {

> +        printk("Error during GICC entries parsing\n");
> +        printk("\nFailed to initialize GIC IRQ controller\n");

One single printk("No valid GICC entries exists\n") would have been enough.

> +        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);

Wrong indentation

> +
> +    if ( res < 0 )

0 means no distributor which means the ACPI is not valid. I would
replace the check by

res <= 0


You also need to check that we don't have multiple GICD entry.

> +    {
> +        printk("Error during GICD entries parsing\n");
> +        printk("\nFailed to initialize GIC IRQ controller\n");

One single printk is enough.

> +        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));

This is coming out of nowhere without any explanation.

I guess this is related to the change in the ACPI table for DOM0, right?
If so, this should not be in the GIC initialization but in a specific
DOM0 building code.

> +    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_gicv2_init();

acpi_gicv2_init is returning an error code. You should not ignore it.

>  
>      /* TODO: Add check on distributor, cpu size */
>  
> @@ -790,7 +906,21 @@ DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
>          .dt_match = gicv2_dt_match,
>          .init = dt_gicv2_preinit,
>  DT_DEVICE_END

Missing blank line.

> +#ifdef CONFIG_ACPI
> +/* Set up the GIC */
> +static int __init acpi_gicv2_preinit(const void *data)
> +{
> +    gicv2_info.hw_version = GIC_V2;
> +    register_gic_ops(&gicv2_ops);
> +
> +    return 0;
> +}
>  
> +ACPI_DEVICE_START(agicv2, "GICv2", DEVICE_GIC)
> +        .class_type = GIC_V2,
> +        .init = acpi_gicv2_preinit,
> +ACPI_DEVICE_END
> +#endif
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 701c306..e33bfd7 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -27,6 +27,7 @@
>  #include <xen/softirq.h>
>  #include <xen/list.h>
>  #include <xen/device_tree.h>
> +#include <xen/acpi.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  #include <asm/platform.h>
> @@ -34,6 +35,7 @@
>  #include <asm/io.h>
>  #include <asm/gic.h>
>  #include <asm/vgic.h>
> +#include <asm/acpi.h>
>  
>  static void gic_restore_pending_irqs(struct vcpu *v);
>  
> @@ -261,9 +263,23 @@ void __init dt_gic_preinit(void)
>      dt_device_set_used_by(node, DOMID_XEN);
>  }
>  
> +static void __init acpi_gic_init(void)

This function should be called acpi_gic_preinit as it's used during
pre-initialization.

> +{
> +    int rc;
> +
> +    /* NOTE: Only one GIC is supported */
> +    /* hardcode to gic v2 for now */
> +    rc = acpi_device_init(DEVICE_GIC, NULL, GIC_V2);

This won't work for multiple GIC later. You should not try to use a
generic implementation just because it's there.

If you don't find a way to deal with genericity, I prefer a call to
acpi_gicv2_preinit directly.

> +    if ( rc )
> +        panic("Unable to find compatible GIC in the ACPI table");

This is not true. You check the presence of the GIC ACPI table later.

> +}
> +
>  void __init gic_preinit(void)
>  {
> -    dt_gic_preinit();
> +    if( acpi_disabled )
> +        dt_gic_preinit();
> +    else
> +        acpi_gic_init();
>  }
>  
>  /* Set up the GIC */
> diff --git a/xen/drivers/char/arm-uart.c b/xen/drivers/char/arm-uart.c
> new file mode 100644
> index 0000000..2603508
> --- /dev/null
> +++ b/xen/drivers/char/arm-uart.c

This file doesn't belong to this patch. I will review it when it will be
placed in the right patch.

Regards,

-- 
Julien Grall

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

[Parth Dixit]

+shannon

On 21 May 2015 at 17:59, Julien Grall <julien.grall@citrix.com> 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 <tomasz.nowicki@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>>  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 <xen/list.h>
>>  #include <xen/device_tree.h>
>>  #include <xen/libfdt/libfdt.h>
>> +#include <xen/acpi.h>
>> +#include <acpi/actables.h>
>>  #include <asm/p2m.h>
>>  #include <asm/domain.h>
>>  #include <asm/platform.h>
>> @@ -35,6 +37,7 @@
>>
>>  #include <asm/io.h>
>>  #include <asm/gic.h>
>> +#include <asm/acpi.h>
>>
>>  /*
>>   * 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 would rename it to count.
>
>> +
>> +    status = acpi_get_table(ACPI_SIG_MADT, 0, &table);
>
> For a generic ACPI device code it would make sense to pass the ACPI
> table in parameter as you will likely have to retrieve the same table
> within the same class of device (see Serial too).
>
>> +
>> +    if ( ACPI_FAILURE(status) )
>> +    {
>
> Wrong indentation within the block.
>
>> +              const char *msg = acpi_format_exception(status);
>
> Missing blank line
>
>> +              printk("\nFailed to get MADT table, %s\n", msg);
>
> The first "\n" is not necessary.
>
>> +              return 1;
>
> Please return a meaningful error code.
>
>> +    }
>> +
>> +    /* 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);
>
> Wrong indentation
>
>> +    if ( res < 0 )
>
> 0 means the no GICC which should be throwing an error too. I would
> replace the check by
>
> res <= 0
>
>> +    {
>
>> +        printk("Error during GICC entries parsing\n");
>> +        printk("\nFailed to initialize GIC IRQ controller\n");
>
> One single printk("No valid GICC entries exists\n") would have been enough.
>
>> +        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);
>
> Wrong indentation
>
>> +
>> +    if ( res < 0 )
>
> 0 means no distributor which means the ACPI is not valid. I would
> replace the check by
>
> res <= 0
>
>
> You also need to check that we don't have multiple GICD entry.
>
>> +    {
>> +        printk("Error during GICD entries parsing\n");
>> +        printk("\nFailed to initialize GIC IRQ controller\n");
>
> One single printk is enough.
>
>> +        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));
>
> This is coming out of nowhere without any explanation.
>
> I guess this is related to the change in the ACPI table for DOM0, right?
> If so, this should not be in the GIC initialization but in a specific
> DOM0 building code.
>
>> +    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_gicv2_init();
>
> acpi_gicv2_init is returning an error code. You should not ignore it.
>
>>
>>      /* TODO: Add check on distributor, cpu size */
>>
>> @@ -790,7 +906,21 @@ DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
>>          .dt_match = gicv2_dt_match,
>>          .init = dt_gicv2_preinit,
>>  DT_DEVICE_END
>
> Missing blank line.
>
>> +#ifdef CONFIG_ACPI
>> +/* Set up the GIC */
>> +static int __init acpi_gicv2_preinit(const void *data)
>> +{
>> +    gicv2_info.hw_version = GIC_V2;
>> +    register_gic_ops(&gicv2_ops);
>> +
>> +    return 0;
>> +}
>>
>> +ACPI_DEVICE_START(agicv2, "GICv2", DEVICE_GIC)
>> +        .class_type = GIC_V2,
>> +        .init = acpi_gicv2_preinit,
>> +ACPI_DEVICE_END
>> +#endif
>>  /*
>>   * Local variables:
>>   * mode: C
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 701c306..e33bfd7 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -27,6 +27,7 @@
>>  #include <xen/softirq.h>
>>  #include <xen/list.h>
>>  #include <xen/device_tree.h>
>> +#include <xen/acpi.h>
>>  #include <asm/p2m.h>
>>  #include <asm/domain.h>
>>  #include <asm/platform.h>
>> @@ -34,6 +35,7 @@
>>  #include <asm/io.h>
>>  #include <asm/gic.h>
>>  #include <asm/vgic.h>
>> +#include <asm/acpi.h>
>>
>>  static void gic_restore_pending_irqs(struct vcpu *v);
>>
>> @@ -261,9 +263,23 @@ void __init dt_gic_preinit(void)
>>      dt_device_set_used_by(node, DOMID_XEN);
>>  }
>>
>> +static void __init acpi_gic_init(void)
>
> This function should be called acpi_gic_preinit as it's used during
> pre-initialization.
>
>> +{
>> +    int rc;
>> +
>> +    /* NOTE: Only one GIC is supported */
>> +    /* hardcode to gic v2 for now */
>> +    rc = acpi_device_init(DEVICE_GIC, NULL, GIC_V2);
>
> This won't work for multiple GIC later. You should not try to use a
> generic implementation just because it's there.
>
> If you don't find a way to deal with genericity, I prefer a call to
> acpi_gicv2_preinit directly.
>
>> +    if ( rc )
>> +        panic("Unable to find compatible GIC in the ACPI table");
>
> This is not true. You check the presence of the GIC ACPI table later.
>
>> +}
>> +
>>  void __init gic_preinit(void)
>>  {
>> -    dt_gic_preinit();
>> +    if( acpi_disabled )
>> +        dt_gic_preinit();
>> +    else
>> +        acpi_gic_init();
>>  }
>>
>>  /* Set up the GIC */
>> diff --git a/xen/drivers/char/arm-uart.c b/xen/drivers/char/arm-uart.c
>> new file mode 100644
>> index 0000000..2603508
>> --- /dev/null
>> +++ b/xen/drivers/char/arm-uart.c
>
> This file doesn't belong to this patch. I will review it when it will be
> placed in the right patch.
>
> Regards,
>
> --
> Julien Grall

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

[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 <parth.dixit@linaro.org>
---
 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..0000000
--- 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 <julien.grall@linaro.org>
- * 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 <asm/device.h>
-#include <asm/types.h>
-#include <xen/console.h>
-#include <xen/device_tree.h>
-#include <xen/serial.h>
-#include <xen/errno.h>
-
-/*
- * 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,
     .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;
 
-    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;
     }
 
-    uart->vuart.base_addr = addr;
-    uart->vuart.size = size;
-    uart->vuart.data_off = DR;
-    uart->vuart.status_off = FR;
-    uart->vuart.status = 0;
-
     /* Register with generic serial driver. */
     serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
 
@@ -293,7 +304,7 @@ static const struct dt_device_match pl011_dt_match[] __initconst =
 
 DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
         .dt_match = pl011_dt_match,
-        .init = pl011_uart_init,
+        .init = dt_pl011_uart_init,
 DT_DEVICE_END
 
 /*
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 71e6ade..484a6a8 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -98,6 +98,7 @@ struct uart_driver {
 #define SERHND_HI       (1<<2) /* Mux/demux each transferred char by MSB. */
 #define SERHND_LO       (1<<3) /* Ditto, except that the MSB is cleared.  */
 #define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?    */
+#define SERHND_UART     (0<<0) /* handler configured from ACPI */
 
 /* Two-stage initialisation (before/after IRQ-subsystem initialisation). */
 void serial_init_preirq(void);
@@ -170,7 +171,7 @@ struct ns16550_defaults {
 void ns16550_init(int index, struct ns16550_defaults *defaults);
 void ehci_dbgp_init(void);
 
-void __init dt_uart_init(void);
+void __init uart_init(void);
 
 struct physdev_dbgp_op;
 int dbgp_op(const struct physdev_dbgp_op *);
-- 
1.9.1

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
> --- 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

The patch is missing the corresponding source file.

Also. uart_init() being (presumably) implemented in that file is in
no way "generic" - it's still ARM specific, and hence it should be
named that way.

Jan

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

[Julien Grall]

Hi,

On 18/05/15 09:20, Jan Beulich wrote:
>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>> --- 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
> 
> The patch is missing the corresponding source file.

Parth, the file can be found in a previous unrelated patch:

http://lists.xen.org/archives/html/xen-devel/2015-05/msg02208.html

Regards,

-- 
Julien Grall

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

[Julien Grall]

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.

> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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;
>      }
>  
> -    uart->vuart.base_addr = addr;
> -    uart->vuart.size = size;
> -    uart->vuart.data_off = DR;
> -    uart->vuart.status_off = FR;
> -    uart->vuart.status = 0;
> -
>      /* Register with generic serial driver. */
>      serial_register_uart(SERHND_DTUART, &pl011_driver, uart);

This could be moved in pl011_uart_init. With the other changes suggested
above, you don't need anymore the variable uart here and the code would
be more compact.

>  
> @@ -293,7 +304,7 @@ static const struct dt_device_match pl011_dt_match[] __initconst =
>  
>  DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
>          .dt_match = pl011_dt_match,
> -        .init = pl011_uart_init,
> +        .init = dt_pl011_uart_init,
>  DT_DEVICE_END
>  
>  /*
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 71e6ade..484a6a8 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -98,6 +98,7 @@ struct uart_driver {
>  #define SERHND_HI       (1<<2) /* Mux/demux each transferred char by MSB. */
>  #define SERHND_LO       (1<<3) /* Ditto, except that the MSB is cleared.  */
>  #define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?    */
> +#define SERHND_UART     (0<<0) /* handler configured from ACPI */

Why did you introduce a new SERHND rather than renaming SERHND_DTUART?

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 5679 bytes --]

On 21 May 2015 at 16:58, Julien Grall <julien.grall@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.

> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > ---
> >  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;
> >      }
> >
> > -    uart->vuart.base_addr = addr;
> > -    uart->vuart.size = size;
> > -    uart->vuart.data_off = DR;
> > -    uart->vuart.status_off = FR;
> > -    uart->vuart.status = 0;
> > -
> >      /* Register with generic serial driver. */
> >      serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
>
> This could be moved in pl011_uart_init. With the other changes suggested
> above, you don't need anymore the variable uart here and the code would
> be more compact.
>
> >
> > @@ -293,7 +304,7 @@ static const struct dt_device_match pl011_dt_match[]
> __initconst =
> >
> >  DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
> >          .dt_match = pl011_dt_match,
> > -        .init = pl011_uart_init,
> > +        .init = dt_pl011_uart_init,
> >  DT_DEVICE_END
> >
> >  /*
> > diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> > index 71e6ade..484a6a8 100644
> > --- a/xen/include/xen/serial.h
> > +++ b/xen/include/xen/serial.h
> > @@ -98,6 +98,7 @@ struct uart_driver {
> >  #define SERHND_HI       (1<<2) /* Mux/demux each transferred char by
> MSB. */
> >  #define SERHND_LO       (1<<3) /* Ditto, except that the MSB is
> cleared.  */
> >  #define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?
>   */
> > +#define SERHND_UART     (0<<0) /* handler configured from ACPI */
>
> Why did you introduce a new SERHND rather than renaming SERHND_DTUART?
>
> Regards,
>
> --
> Julien Grall
>

[-- Attachment #1.2: Type: text/html, Size: 7676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Julien Grall]

On 24/05/2015 08:07, Parth Dixit wrote:
>
>
> On 21 May 2015 at 16:58, Julien Grall <julien.grall@citrix.com
> <mailto:julien.grall@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

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

[Parth Dixit]

+shannon

On 24 May 2015 at 13:18, Julien Grall <julien.grall@citrix.com> wrote:
>
> On 24/05/2015 08:07, Parth Dixit wrote:
>>
>>
>>
>> On 21 May 2015 at 16:58, Julien Grall <julien.grall@citrix.com
>> <mailto:julien.grall@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

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

[Parth Dixit]

Parse ACPI SPCR (Serial Port Console Redirection table) table and
initialize the serial port pl011.

Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <asm/device.h>
 #include <xen/mm.h>
 #include <xen/vmap.h>
+#include <xen/acpi.h>
 #include <asm/pl011-uart.h>
 #include <asm/io.h>
 
@@ -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

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

[Julien Grall]

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

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

[Parth Dixit]

+shannon

On 26 May 2015 at 20:34, Julien Grall <julien.grall@citrix.com> 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

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

[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 <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <asm/regs.h>
 #include <xen/errno.h>
 #include <xen/device_tree.h>
+#include <xen/acpi.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/guest_access.h>
 #include <xen/iocap.h>
@@ -18,6 +19,7 @@
 #include <asm/psci.h>
 #include <asm/setup.h>
 #include <asm/cpufeature.h>
+#include <asm/acpi.h>
 
 #include <asm/gic.h>
 #include <xen/irq.h>
@@ -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

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

[Julien Grall]

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 <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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 <asm/regs.h>
>  #include <xen/errno.h>
>  #include <xen/device_tree.h>
> +#include <xen/acpi.h>
>  #include <xen/libfdt/libfdt.h>
>  #include <xen/guest_access.h>
>  #include <xen/iocap.h>
> @@ -18,6 +19,7 @@
>  #include <asm/psci.h>
>  #include <asm/setup.h>
>  #include <asm/cpufeature.h>
> +#include <asm/acpi.h>

Not necessary, xen/acpi.h already includes asm/acpi.h

>  
>  #include <asm/gic.h>
>  #include <xen/irq.h>
> @@ -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 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)

if ( ... )

> +        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,
> +};
> +

This doesn't belong to this patch ...

>  #define ACPI_GTDT_INTR_MASK ( ACPI_GTDT_INTERRUPT_MODE | ACPI_GTDT_INTERRUPT_POLARITY )
>  
>  /**
> 

Regards,

-- 
Julien Grall

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

[Parth Dixit]

+shannon

On 2 June 2015 at 22:57, Julien Grall <julien.grall@citrix.com> 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 <naresh.bhat@linaro.org>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>>  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 <asm/regs.h>
>>  #include <xen/errno.h>
>>  #include <xen/device_tree.h>
>> +#include <xen/acpi.h>
>>  #include <xen/libfdt/libfdt.h>
>>  #include <xen/guest_access.h>
>>  #include <xen/iocap.h>
>> @@ -18,6 +19,7 @@
>>  #include <asm/psci.h>
>>  #include <asm/setup.h>
>>  #include <asm/cpufeature.h>
>> +#include <asm/acpi.h>
>
> Not necessary, xen/acpi.h already includes asm/acpi.h
>
>>
>>  #include <asm/gic.h>
>>  #include <xen/irq.h>
>> @@ -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 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)
>
> if ( ... )
>
>> +        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,
>> +};
>> +
>
> This doesn't belong to this patch ...
>
>>  #define ACPI_GTDT_INTR_MASK ( ACPI_GTDT_INTERRUPT_MODE | ACPI_GTDT_INTERRUPT_POLARITY )
>>
>>  /**
>>
>
> Regards,
>
> --
> Julien Grall

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

[Parth Dixit]

Create a chosen node for DOM0 with
 - bootargs
 - initrd

Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

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 <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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

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

[Parth Dixit]

+shannon

On 2 June 2015 at 23:10, Julien Grall <julien.grall@citrix.com> 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 <naresh.bhat@linaro.org>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>>  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

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

[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 <parth.dixit@linaro.org>
---
 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 <xen/errno.h>
 #include <xen/device_tree.h>
 #include <xen/acpi.h>
+#include <xen/efi.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/guest_access.h>
 #include <xen/iocap.h>
@@ -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

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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.

Jan

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 1237 bytes --]

On 20 May 2015 at 21:46, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 2093 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Jan Beulich]

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

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

[Jan Beulich]

>>> On 26.05.15 at 10:21, <JBeulich@suse.com> wrote:
> 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).

Ah, looks like this is a result of you sending HTML mails. Please stop
doing so.

Jan

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

[Parth Dixit]

+shannon

On 26 May 2015 at 13:51, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 24.05.15 at 08:30, <parth.dixit@linaro.org> wrote:
>> On 20 May 2015 at 21:46, Jan Beulich <JBeulich@suse.com> wrote:
>>
>>> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
>

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

[Parth Dixit]

Status override table is used to hide devices from DOM0
that are used by xen

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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

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

[Parth Dixit]

+shannon

On 18 May 2015 at 01:33, Parth Dixit <parth.dixit@linaro.org> wrote:
> Status override table is used to hide devices from DOM0
> that are used by xen
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
>  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
>

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

[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 <parth.dixit@linaro.org>
---
 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

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
> Xen environment table is ACPI table that is used to pass grant table
> and event channel interrupt information to dom0.

The documents linked to by the uefi.org web site don't look like these
are final, formally acceptable definitions. I'm not sure we want to
include potentially in flux things in the hypervisor when it is not clear
whether by the next release these would get finalized.

Apart from that I could do with an explanation of why the XENV table
is needed in the first place, considering that on x86 we get away
without.

Jan

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

[Julien Grall]

Hi Jan,

On 20/05/15 17:22, Jan Beulich wrote:
>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>> Xen environment table is ACPI table that is used to pass grant table
>> and event channel interrupt information to dom0.
> 
> The documents linked to by the uefi.org web site don't look like these
> are final, formally acceptable definitions. I'm not sure we want to
> include potentially in flux things in the hypervisor when it is not clear
> whether by the next release these would get finalized.

What do you mean by "formally acceptable definitions"?

The XENV table is final and accepted as a separate table handle by Xen
Project.

I would have to dig into my mail to find why we decide to only give a URL...

> Apart from that I could do with an explanation of why the XENV table
> is needed in the first place, considering that on x86 we get away
> without.

When you boot DOM0 on ARM there is no way to know that we are running on
Xen (no cpuid like, no specific boot path,...). For the device tree, we
include a new node. For ACPI, this table allow us to know the we are
running on Xen.

Furthermore, on x86 all these informations are passed via the start_info
structure which doesn't exits on ARM. And there would be no easy way to
pass it to DOM0 at startup (the memory layout is different from every
board).

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 20.05.15 at 19:00, <julien.grall@citrix.com> wrote:
> On 20/05/15 17:22, Jan Beulich wrote:
>>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>>> Xen environment table is ACPI table that is used to pass grant table
>>> and event channel interrupt information to dom0.
>> 
>> The documents linked to by the uefi.org web site don't look like these
>> are final, formally acceptable definitions. I'm not sure we want to
>> include potentially in flux things in the hypervisor when it is not clear
>> whether by the next release these would get finalized.
> 
> What do you mean by "formally acceptable definitions"?

Oops, sorry - s/acceptable/accepted/.

> The XENV table is final and accepted as a separate table handle by Xen
> Project.
> 
> I would have to dig into my mail to find why we decide to only give a URL...

The linked to document (on our wiki) is versioned 0.<something>,
which doesn't look like a final stable version. The same applies to
the other (STAO?) one.

>> Apart from that I could do with an explanation of why the XENV table
>> is needed in the first place, considering that on x86 we get away
>> without.
> 
> When you boot DOM0 on ARM there is no way to know that we are running on
> Xen (no cpuid like, no specific boot path,...).

Iirc ARM has a CPUID like identification mechanism - why can't that
be used? And if it can't be used, considering that namely ARM64
basically has virtualization support designed in from the beginning,
doesn't this look like a design flaw? After all - do you really see
each hypervisor kind to define their own ACPI table as a proper,
scalable mechanism?

> For the device tree, we
> include a new node. For ACPI, this table allow us to know the we are
> running on Xen.

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.

> Furthermore, on x86 all these informations are passed via the start_info
> structure which doesn't exits on ARM. And there would be no easy way to
> pass it to DOM0 at startup (the memory layout is different from every
> board).

There's no start_info structure for x86 HVM. And passing a pointer
to the entry point in a register, or via EFI GUID (as you seem to tie
together ACPI and EFI presence) could have done the same.

Jan

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

[Julien Grall]

Hi Jan,

On 21/05/15 07:22, Jan Beulich wrote:
>>>> On 20.05.15 at 19:00, <julien.grall@citrix.com> wrote:
>> On 20/05/15 17:22, Jan Beulich wrote:
>>>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> wrote:
>>>> Xen environment table is ACPI table that is used to pass grant table
>>>> and event channel interrupt information to dom0.
>>>
>>> The documents linked to by the uefi.org web site don't look like these
>>> are final, formally acceptable definitions. I'm not sure we want to
>>> include potentially in flux things in the hypervisor when it is not clear
>>> whether by the next release these would get finalized.
>>
>> What do you mean by "formally acceptable definitions"?
> 
> Oops, sorry - s/acceptable/accepted/.
> 
>> The XENV table is final and accepted as a separate table handle by Xen
>> Project.
>>
>> I would have to dig into my mail to find why we decide to only give a URL...
> 
> The linked to document (on our wiki) is versioned 0.<something>,
> 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.

> 
>>> Apart from that I could do with an explanation of why the XENV table
>>> is needed in the first place, considering that on x86 we get away
>>> without.
>>
>> When you boot DOM0 on ARM there is no way to know that we are running on
>> Xen (no cpuid like, no specific boot path,...).
> 
> Iirc ARM has a CPUID like identification mechanism - why can't that
> be used? And if it can't be used, considering that namely ARM64
> basically has virtualization support designed in from the beginning,
> doesn't this look like a design flaw? After all - do you really see
> each hypervisor kind to define their own ACPI table as a proper,
> scalable mechanism?

The ARM CPUID describe the hardware but doesn't offer the opportunity to
extend it as x86 in order to expose Hypervisor specific CPUID.

I know there was some discussion about adding Hypervisor CPUID but so
far it's not in the spec. We have to deal with it.

>> For the device tree, we
>> include a new node. For ACPI, this table allow us to know the we are
>> running on Xen.
> 
> 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.

The "OEMx" could have clashed with the one provided by the hardware.

With a separate signature reserved ("XENV" is reserved since ACPI 6.0)
we avoid any clash.

>> Furthermore, on x86 all these informations are passed via the start_info
>> structure which doesn't exits on ARM. And there would be no easy way to
>> pass it to DOM0 at startup (the memory layout is different from every
>> board).
> 
> There's no start_info structure for x86 HVM. And passing a pointer
> to the entry point in a register, or via EFI GUID (as you seem to tie
> together ACPI and EFI presence) could have done the same.

The entry point register is not an option. The current impact of XEN ARM
in the OS is very miminal and mostly self-contained. We would like to
keep the same impact with the ACPI support.

There was some concerns about exposing start_info to ARM. I don't
exactly remember which one. I will let Ian, Stefano answer to this.

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
> On 21/05/15 07:22, Jan Beulich wrote:
>> The linked to document (on our wiki) is versioned 0.<something>,
>> 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?

>>> For the device tree, we
>>> include a new node. For ACPI, this table allow us to know the we are
>>> running on Xen.
>> 
>> 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.

Jan

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

[Julien Grall]

On 21/05/15 11:46, Jan Beulich wrote:
>>>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
>> On 21/05/15 07:22, Jan Beulich wrote:
>>> The linked to document (on our wiki) is versioned 0.<something>,
>>> 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.

>From the ACPI perspective, only the signature has been reserved in order
to avoid someone else using it.

>>>> For the device tree, we
>>>> include a new node. For ACPI, this table allow us to know the we are
>>>> running on Xen.
>>>
>>> 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...

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 21.05.15 at 12:52, <julien.grall@citrix.com> wrote:
> On 21/05/15 11:46, Jan Beulich wrote:
>>>>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
>>> On 21/05/15 07:22, Jan Beulich wrote:
>>>> The linked to document (on our wiki) is versioned 0.<something>,
>>>> 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.

>>>> 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.

Jan

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

[Julien Grall]

On 21/05/15 12:38, Jan Beulich wrote:
>>>> On 21.05.15 at 12:52, <julien.grall@citrix.com> wrote:
>> On 21/05/15 11:46, Jan Beulich wrote:
>>>>>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
>>>> On 21/05/15 07:22, Jan Beulich wrote:
>>>>> The linked to document (on our wiki) is versioned 0.<something>,
>>>>> 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.

Regards,

-- 
Julien Grall

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 1942 bytes --]

On 21 May 2015 at 17:11, Julien Grall <julien.grall@citrix.com> wrote:

> On 21/05/15 12:38, Jan Beulich wrote:
> >>>> On 21.05.15 at 12:52, <julien.grall@citrix.com> wrote:
> >> On 21/05/15 11:46, Jan Beulich wrote:
> >>>>>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
> >>>> On 21/05/15 07:22, Jan Beulich wrote:
> >>>>> The linked to document (on our wiki) is versioned 0.<something>,
> >>>>> 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
>

[-- Attachment #1.2: Type: text/html, Size: 3088 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Julien Grall]

On 24/05/2015 09:16, Parth Dixit wrote:
>
>
> On 21 May 2015 at 17:11, Julien Grall <julien.grall@citrix.com
> <mailto:julien.grall@citrix.com>> wrote:
>
>     On 21/05/15 12:38, Jan Beulich wrote:
>     >>>> On 21.05.15 at 12:52, <julien.grall@citrix.com <mailto:julien.grall@citrix.com>> wrote:
>     >> On 21/05/15 11:46, Jan Beulich wrote:
>     >>>>>> On 21.05.15 at 12:34, <julien.grall@citrix.com <mailto:julien.grall@citrix.com>> wrote:
>     >>>> On 21/05/15 07:22, Jan Beulich wrote:
>     >>>>> The linked to document (on our wiki) is versioned 0.<something>,
>     >>>>> 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?

I would wait input from Stefano and Ian.

As we are talking about boot protocol, some maintainers such as Jan 
comes from the x86 world which as a different way to boot... They are 
not aware of all the background talk (during connect and by mail) we had 
and the requirements in order to make this series.
Can you provide an up to date doc/wiki page to explain how every 
components works together (i.e UEFI, boot protocol, DT, requirements...)?

> if yes, i'll remove xenv table and add a new patch for hypercall, please
> confirm.

I think we should make a consensus on the boot protocol before doing any 
change on this series.

Regards,

-- 
Julien Grall

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

[Stefano Stabellini]

On Thu, 21 May 2015, Jan Beulich wrote:
> >>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
> > On 21/05/15 07:22, Jan Beulich wrote:
> >> The linked to document (on our wiki) is versioned 0.<something>,
> >> 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?

Sorry Jan, it would have been far nicer to discuss this in public with
the community, but unfortunately one needs to be a UEFI Forum member to
be able to submit requests to it. Both Citrix and Linaro are.

But the good news is that now that we positively reserved a signature
("XENV") and we established that the relative table is externally
handled by Xen Project, we can safely discuss the evolution of the spec
in public.

But we should have sent an email to xen-devel about this sooner, sorry.


> >>> For the device tree, we
> >>> include a new node. For ACPI, this table allow us to know the we are
> >>> running on Xen.
> >> 
> >> 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.

Let me give you some more context.

As Julien pointed out, neither the "cpuid" like mechanism nor the
existing ACPI tables seemed to fit the bill, so we thought that the best
way forward was to simply add one more ACPI table to advertise the
presence of Xen on the platform.

Since we have a table in our hands, we might as well use it to pass some
useful information, specifically we thought that the existing
information passed via device tree would be a good place to start. This
is how we got to the XENV table that we have now.

In general I think that passing information via tables or data trees,
that are made for this purpose, is nicer compared to using hypercalls.

Regarding stable vs non-stable, the discussion is off point. What
matters is the version number. We can implement the current version of
the spec, v0.2, or we can make changes to it, introduce a new version
and implement that one instead. We can pick any version number we like.

I am biased because I contributed to the current spec, so I think that
the version we have is reasonable, but if we want to change it that's
also OK for me.  In fact if you like it, I guess we could try to make it
arch-independent and use it on x86 too.

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

[Jan Beulich]

>>> On 26.05.15 at 19:34, <stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 21 May 2015, Jan Beulich wrote:
>> >>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
>> > 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.
> 
> Let me give you some more context.
> 
> As Julien pointed out, neither the "cpuid" like mechanism nor the
> existing ACPI tables seemed to fit the bill, so we thought that the best
> way forward was to simply add one more ACPI table to advertise the
> presence of Xen on the platform.
> 
> Since we have a table in our hands, we might as well use it to pass some
> useful information, specifically we thought that the existing
> information passed via device tree would be a good place to start. This
> is how we got to the XENV table that we have now.
> 
> In general I think that passing information via tables or data trees,
> that are made for this purpose, is nicer compared to using hypercalls.

There are certainly up and down sides to each of them. For ACPI
tables, I'm particularly puzzled by the need to re-write XSDT/RSDT
if you want to add a table of your own to what came from firmware.
Which in turn requires the EFI configuration table to be modified or
replaced. Doable, but I doubt this is a very clean approach.

If this was only for DomU (where the tables gets crafted from
scratch anyway) it would be a different thing. But my understanding
so far was that this is particularly also (if not exclusively) for Dom0.

> Regarding stable vs non-stable, the discussion is off point. What
> matters is the version number. We can implement the current version of
> the spec, v0.2, or we can make changes to it, introduce a new version
> and implement that one instead. We can pick any version number we like.

Prior to a first consumer implementation - yes. But afterwards you
need to remain backwards compatible.

> I am biased because I contributed to the current spec, so I think that
> the version we have is reasonable, but if we want to change it that's
> also OK for me.  In fact if you like it, I guess we could try to make it
> arch-independent and use it on x86 too.

As you may already have guessed from my earlier response - I'd rather
not, unless unavoidable.

Jan

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

[Stefano Stabellini]

On Wed, 27 May 2015, Jan Beulich wrote:
> >>> On 26.05.15 at 19:34, <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 21 May 2015, Jan Beulich wrote:
> >> >>> On 21.05.15 at 12:34, <julien.grall@citrix.com> wrote:
> >> > 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.
> > 
> > Let me give you some more context.
> > 
> > As Julien pointed out, neither the "cpuid" like mechanism nor the
> > existing ACPI tables seemed to fit the bill, so we thought that the best
> > way forward was to simply add one more ACPI table to advertise the
> > presence of Xen on the platform.
> > 
> > Since we have a table in our hands, we might as well use it to pass some
> > useful information, specifically we thought that the existing
> > information passed via device tree would be a good place to start. This
> > is how we got to the XENV table that we have now.
> > 
> > In general I think that passing information via tables or data trees,
> > that are made for this purpose, is nicer compared to using hypercalls.
> 
> There are certainly up and down sides to each of them. For ACPI
> tables, I'm particularly puzzled by the need to re-write XSDT/RSDT
> if you want to add a table of your own to what came from firmware.
> Which in turn requires the EFI configuration table to be modified or
> replaced. Doable, but I doubt this is a very clean approach.

We already have to do stuff like that on ARM for other things too,
for example we modify the GIC and timer tables.


> If this was only for DomU (where the tables gets crafted from
> scratch anyway) it would be a different thing. But my understanding
> so far was that this is particularly also (if not exclusively) for Dom0.

Yes, your understanding is correct.


> > Regarding stable vs non-stable, the discussion is off point. What
> > matters is the version number. We can implement the current version of
> > the spec, v0.2, or we can make changes to it, introduce a new version
> > and implement that one instead. We can pick any version number we like.
> 
> Prior to a first consumer implementation - yes. But afterwards you
> need to remain backwards compatible.

But this would be the same as for the hypercall, right? Except that I
guess it is easier to version a table than an hypercall.


> > I am biased because I contributed to the current spec, so I think that
> > the version we have is reasonable, but if we want to change it that's
> > also OK for me.  In fact if you like it, I guess we could try to make it
> > arch-independent and use it on x86 too.
> 
> As you may already have guessed from my earlier response - I'd rather
> not, unless unavoidable.

Sure, we don't have to do the same thing here between x86 and ARM here.
For Xen on ARM we have been trying to export a set of ACPI tables that
actually matches the combination of virtual or physical hardware that
Dom0 is seeing. On x86 things are different.


Let's take a closer look at this table. After the boilierplate, these
are the interesting fields:

GNT Start, GNT Size
Evtchn Intr, Evtchn Intr Flags

After the table, it is clearly stated:

"The Grant Table region is optional."

and

"The Event Channel Interrupt is optional."

So I think there is no problem: we don't want to pass any info in that
table? Sure, let's not pass any. We can still use it to flag the
presence of Xen on the platform.

If we agree to that, we can move on to discussing whether we prefer to
pass the grant table region and evtchn interrupt via XENV or another
mechanism.

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

[Jan Beulich]

>>> On 28.05.15 at 12:58, <stefano.stabellini@eu.citrix.com> wrote:
> Let's take a closer look at this table. After the boilierplate, these
> are the interesting fields:
> 
> GNT Start, GNT Size
> Evtchn Intr, Evtchn Intr Flags
> 
> After the table, it is clearly stated:
> 
> "The Grant Table region is optional."
> 
> and
> 
> "The Event Channel Interrupt is optional."
> 
> So I think there is no problem: we don't want to pass any info in that
> table? Sure, let's not pass any. We can still use it to flag the
> presence of Xen on the platform.

Even more so a reason to use what base ACPI has, without any
custom table.

Jan

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

[Stefano Stabellini]

On Thu, 28 May 2015, Jan Beulich wrote:
> >>> On 28.05.15 at 12:58, <stefano.stabellini@eu.citrix.com> wrote:
> > Let's take a closer look at this table. After the boilierplate, these
> > are the interesting fields:
> > 
> > GNT Start, GNT Size
> > Evtchn Intr, Evtchn Intr Flags
> > 
> > After the table, it is clearly stated:
> > 
> > "The Grant Table region is optional."
> > 
> > and
> > 
> > "The Event Channel Interrupt is optional."
> > 
> > So I think there is no problem: we don't want to pass any info in that
> > table? Sure, let's not pass any. We can still use it to flag the
> > presence of Xen on the platform.
> 
> Even more so a reason to use what base ACPI has, without any
> custom table.

Could you please make a concrete suggestion with table names and fields?

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

[Jan Beulich]

>>> On 28.05.15 at 14:12, <stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 28 May 2015, Jan Beulich wrote:
>> >>> On 28.05.15 at 12:58, <stefano.stabellini@eu.citrix.com> wrote:
>> > Let's take a closer look at this table. After the boilierplate, these
>> > are the interesting fields:
>> > 
>> > GNT Start, GNT Size
>> > Evtchn Intr, Evtchn Intr Flags
>> > 
>> > After the table, it is clearly stated:
>> > 
>> > "The Grant Table region is optional."
>> > 
>> > and
>> > 
>> > "The Event Channel Interrupt is optional."
>> > 
>> > So I think there is no problem: we don't want to pass any info in that
>> > table? Sure, let's not pass any. We can still use it to flag the
>> > presence of Xen on the platform.
>> 
>> Even more so a reason to use what base ACPI has, without any
>> custom table.
> 
> 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".

Jan

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

[Stefano Stabellini]

On Thu, 28 May 2015, Jan Beulich wrote:
> >>> On 28.05.15 at 14:12, <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 28 May 2015, Jan Beulich wrote:
> >> >>> On 28.05.15 at 12:58, <stefano.stabellini@eu.citrix.com> wrote:
> >> > Let's take a closer look at this table. After the boilierplate, these
> >> > are the interesting fields:
> >> > 
> >> > GNT Start, GNT Size
> >> > Evtchn Intr, Evtchn Intr Flags
> >> > 
> >> > After the table, it is clearly stated:
> >> > 
> >> > "The Grant Table region is optional."
> >> > 
> >> > and
> >> > 
> >> > "The Event Channel Interrupt is optional."
> >> > 
> >> > So I think there is no problem: we don't want to pass any info in that
> >> > table? Sure, let's not pass any. We can still use it to flag the
> >> > presence of Xen on the platform.
> >> 
> >> Even more so a reason to use what base ACPI has, without any
> >> custom table.
> > 
> > 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.

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

[Jan Beulich]

>>> On 29.05.15 at 12:31, <stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 28 May 2015, Jan Beulich wrote:
>> >>> On 28.05.15 at 14:12, <stefano.stabellini@eu.citrix.com> 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

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

[Parth Dixit]

+shannon

On 29 May 2015 at 16:13, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 29.05.15 at 12:31, <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 28 May 2015, Jan Beulich wrote:
>>> >>> On 28.05.15 at 14:12, <stefano.stabellini@eu.citrix.com> 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
>

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

[Parth Dixit]

creates a helper function for mapping with cached attributes

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>   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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 19:35, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
>> ---
>>   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

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

[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 <parth.dixit@linaro.org>
---
 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)0x0000000000000008ULL)	/* 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

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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

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

[Parth Dixit]

+shannon

On 20 May 2015 at 21:55, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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
>

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

[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 <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>   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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 21:39, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
>> ---
>>   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

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

[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 <parth.dixit@linaro.org>
---
 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 <xen/acpi.h>
 #include <asm/mm.h>
 
+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..a9999f6 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -13,6 +13,7 @@
 #include <asm/byteorder.h>
 #include <asm/setup.h>
 #include <xen/libfdt/libfdt.h>
+#include <xen/acpi.h>
 
 #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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>   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 <xen/acpi.h>
>   #include <asm/mm.h>
>
> +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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 21:49, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
>> ---
>>   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 <xen/acpi.h>
>>   #include <asm/mm.h>
>>
>> +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

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

[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 <parth.dixit@linaro.org>
---
 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,0x0000};
 #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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>   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,0x0000};

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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 22:14, Julien Grall <julien.grall.oss@gmail.com> 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 <parth.dixit@linaro.org>
>> ---
>>   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,0x0000};
>
>
> 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

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

[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 <parth.dixit@linaro.org>
---
 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 <xen/softirq.h>
 #include <xen/domain_page.h>
 #include <xen/perfc.h>
+#include <xen/acpi.h>
 #include <public/sched.h>
 #include <public/xen.h>
 #include <asm/debugger.h>
@@ -46,6 +47,7 @@
 #include "vtimer.h"
 #include <asm/gic.h>
 #include <asm/vgic.h>
+#include <xen/iocap.h>
 
 /* 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

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

[Julien Grall]

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.

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

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

[Parth Dixit]

On 8 June 2015 at 22:20, Julien Grall <julien.grall@citrix.com> 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

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

[Julien Grall]

Hi Parth,

On 14/06/2015 11:27, Parth Dixit wrote:
> On 8 June 2015 at 22:20, Julien Grall <julien.grall@citrix.com> 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

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

[Parth Dixit]

+shannon

On 15 June 2015 at 06:49, Julien Grall <julien.grall@citrix.com> wrote:
> Hi Parth,
>
> On 14/06/2015 11:27, Parth Dixit wrote:
>>
>> On 8 June 2015 at 22:20, Julien Grall <julien.grall@citrix.com> 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

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

[Shannon Zhao]

On 2015/7/5 21:30, Parth Dixit wrote:
> +shannon
> 
> On 15 June 2015 at 06:49, Julien Grall <julien.grall@citrix.com> wrote:
>> Hi Parth,
>>
>> On 14/06/2015 11:27, Parth Dixit wrote:
>>>
>>> On 8 June 2015 at 22:20, Julien Grall <julien.grall@citrix.com> 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

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

[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 <shannon.zhao@linaro.org> wrote:
>
>
> On 2015/7/5 21:30, Parth Dixit wrote:
>> +shannon
>>
>> On 15 June 2015 at 06:49, Julien Grall <julien.grall@citrix.com> wrote:
>>> Hi Parth,
>>>
>>> On 14/06/2015 11:27, Parth Dixit wrote:
>>>>
>>>> On 8 June 2015 at 22:20, Julien Grall <julien.grall@citrix.com> 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

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

[Julien Grall]

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.

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

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

[Parth Dixit]

On 31 July 2015 at 00:01, Julien Grall <julien.grall@citrix.com> 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

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

[Shannon Zhao]

On 2015/7/31 2:31, 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.
> 
> 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.
But I guess this will get the all regions except RAM region. And some of
the regions may not exist on hardware. Is it ok to map the non-exist
region to DOM0? Doesn't the map function fail?

> 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).
> 

About the XENV table, from the discussions of the thread, it seems we
reach an agreement on using hypercall to tell DOM0 the grant table info
and event channel irq. Right?

> 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.
> 

Ok, it's good to reach an agreement before action.

> 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.
> 

Which boot protocol? Could you point it out? Thanks. :)

> 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
> 

-- 
Shannon

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

[Julien Grall]

Hi Shannon,

On 31/07/15 02:30, Shannon Zhao wrote:
> 
> 
> On 2015/7/31 2:31, Julien Grall wrote:
>> 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.
>>
>> 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.
> But I guess this will get the all regions except RAM region. And some of
> the regions may not exist on hardware. Is it ok to map the non-exist
> region to DOM0? Doesn't the map function fail?

I don't see a problem for it. I'm not sure what the others think about it.

The map function doesn't know if the physical region is valid or not.
It's only setup the page table to allow the guest using the physical region.

If DOM0 is trying to access invalid region, it will receive a
data/prefetch abort.

> 
>> 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).
>>
> 
> About the XENV table, from the discussions of the thread, it seems we
> reach an agreement on using hypercall to tell DOM0 the grant table info
> and event channel irq. Right?

People have different opinion on what should be the way to boot DOM0
with ACPI on ARM. A design document would help here to understand what
are the possibilities to boot DOM0 (i.e hypercall based, XENV...) and
which one would be the most suitable for ARM.

> 
>> 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.
>>
> 
> Ok, it's good to reach an agreement before action.
> 
>> 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.
>>
> 
> Which boot protocol? Could you point it out? Thanks. :)

The way to boot DOM0 with ACPI. There is a page on the Linaro wiki [1],
but the content is quite out of date now.

Regards,

[1] https://wiki.linaro.org/LEG/Engineering/Virtualization/ACPI_on_Xen

-- 
Julien Grall

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

[Stefano Stabellini]

On Fri, 31 Jul 2015, Julien Grall wrote:
> Hi Shannon,
> 
> On 31/07/15 02:30, Shannon Zhao wrote:
> > 
> > 
> > On 2015/7/31 2:31, Julien Grall wrote:
> >> 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.
> >>
> >> 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.
> > But I guess this will get the all regions except RAM region. And some of
> > the regions may not exist on hardware. Is it ok to map the non-exist
> > region to DOM0? Doesn't the map function fail?
> 
> I don't see a problem for it. I'm not sure what the others think about it.
> 
> The map function doesn't know if the physical region is valid or not.
> It's only setup the page table to allow the guest using the physical region.
> 
> If DOM0 is trying to access invalid region, it will receive a
> data/prefetch abort.

I don't think there is a problem with mapping inexistent memory to dom0.
The only issue is that mapping very large amounts of memory to dom0
takes a lot of memory to store the pagetables themselves in Xen. If we
do that we should definitely use page sizes greater than 4K: 2M or 1G.

I think that starting out with simply relying on the UEFI System Memory
Map would be OK, even though we know that it is not complete. I would
recommend to just do that in the next version of this series and leave
this problem for later. Although I think it should be solved before
completing this work, I wouldn't want everything else to get stuck
because of this. Maybe you could sort out the other issues while we
are still discussing this one.


One option going forward is to map MMIO regions in Dom0 on demand when
trapping in Xen with a data abort. Specifically in
xen/arch/arm/traps.c:do_trap_data_abort_guest we could check that the
guest is dom0 and that the address correspond to a non-ram region not
owned by Xen. If the checks succeed then we map the page in Dom0.


> >> 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).
> >>
> > 
> > About the XENV table, from the discussions of the thread, it seems we
> > reach an agreement on using hypercall to tell DOM0 the grant table info
> > and event channel irq. Right?
> 
> People have different opinion on what should be the way to boot DOM0
> with ACPI on ARM. A design document would help here to understand what
> are the possibilities to boot DOM0 (i.e hypercall based, XENV...) and
> which one would be the most suitable for ARM.

As I wrote previously
(http://marc.info/?i=alpine.DEB.2.02.1505291102390.8130%40kaball.uk.xensource.com),
although I prefer tables, I am OK with hypercalls too, and for the sake
of moving this work forward in the quickest way possible, let's just do
that. This is a minor point on the grand scheme of things.

I suggest you introduce two new hvm params to get the grant table
address and event channel ppi, see xen/include/public/hvm/params.h. They
can be retrieved using the HVMOP_get_param hypercall.

Also remember that if we avoid the XENV table, then we need to set the
new FADT field "Hypervisor Vendor Identity" appropriately to advertise
the presence of Xen on the platform.


> >> 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.
> >>
> > 
> > Ok, it's good to reach an agreement before action.
> > 
> >> 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.
> >>
> > 
> > Which boot protocol? Could you point it out? Thanks. :)
> 
> The way to boot DOM0 with ACPI. There is a page on the Linaro wiki [1],
> but the content is quite out of date now.
> 
> Regards,
> 
> [1] https://wiki.linaro.org/LEG/Engineering/Virtualization/ACPI_on_Xen

http://marc.info/?i=1431893048-5214-1-git-send-email-parth.dixit%40linaro.org
is a good start, but it needs more details. The important thing to clear
out is which information is passed to Dom0 and how, because it will
become a supported external interface going forward.

Specifically:
- what information is passed via the small device tree to dom0 and in
  what format
- how the acpi tables are given to dom0
  * mapped or copied?
  * how do we pass a pointer to them to the kernel?
- if some tables are changed by Xen before passing them on, it would be
  good to list what was changed
  * what tables have been modified
  * what tables have been added
  * what tables have been removed
- how is the memory map passed to Dom0
  * how do we find out the list of MMIO regions, both temporary and
    future solutions
  * how to we tell dom0 where they are

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

[Stefano Stabellini]

On Fri, 31 Jul 2015, Stefano Stabellini wrote:
> On Fri, 31 Jul 2015, Julien Grall wrote:
> > Hi Shannon,
> > 
> > On 31/07/15 02:30, Shannon Zhao wrote:
> > > 
> > > 
> > > On 2015/7/31 2:31, Julien Grall wrote:
> > >> 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.
> > >>
> > >> 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.
> > > But I guess this will get the all regions except RAM region. And some of
> > > the regions may not exist on hardware. Is it ok to map the non-exist
> > > region to DOM0? Doesn't the map function fail?
> > 
> > I don't see a problem for it. I'm not sure what the others think about it.
> > 
> > The map function doesn't know if the physical region is valid or not.
> > It's only setup the page table to allow the guest using the physical region.
> > 
> > If DOM0 is trying to access invalid region, it will receive a
> > data/prefetch abort.
> 
> I don't think there is a problem with mapping inexistent memory to dom0.
> The only issue is that mapping very large amounts of memory to dom0
> takes a lot of memory to store the pagetables themselves in Xen. If we
> do that we should definitely use page sizes greater than 4K: 2M or 1G.
> 
> I think that starting out with simply relying on the UEFI System Memory
> Map would be OK, even though we know that it is not complete. I would
> recommend to just do that in the next version of this series and leave
> this problem for later. Although I think it should be solved before
> completing this work, I wouldn't want everything else to get stuck
> because of this. Maybe you could sort out the other issues while we
> are still discussing this one.
> 
> 
> One option going forward is to map MMIO regions in Dom0 on demand when
> trapping in Xen with a data abort. Specifically in
> xen/arch/arm/traps.c:do_trap_data_abort_guest we could check that the
> guest is dom0 and that the address correspond to a non-ram region not
> owned by Xen. If the checks succeed then we map the page in Dom0.

I am sorry, but I think I confused things further.  I didn't realize
that Parth actually already implemented the mapping on data abort on v2
of the series, on this very patch.

Do not go and change it back to the UEFI Memory Map based approach that
we know it is not reliable.  Please just list the possible solutions to
this problem on the design document, then we'll find consensus on the
best way to move forward.

One more solution that I would like to see investigated, would be to use
an hypercall from Dom0 to request MMIO region mappings, after Linux
completed parsing the DSDT. If we can do this cleanly in Linux, it would
be our best option.  Linux would have to go through all the MMIO regions
and issue an hypercall for each of them to map it.

The hypercall could be XENMEM_add_to_physmap, but we would have to add a
new XENMAPSPACE type to be able to specify an MMIO region as argument.
See xen/include/public/memory.h.

I am not sure where is the best place to issue the hypercall in the
Linux kernel. Perhaps it is possible to list all the registered MMIO
regions somehow. Or perhaps we could use one of the
bus_register_notifiers, like we already do for PCI devices, see
drivers/xen/pci.c. I know that bus_register_notifier can be used with
AMBA and platform buses too.

Maybe you could give a look around at the Linux code and suggest
something?


> > >> 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).
> > >>
> > > 
> > > About the XENV table, from the discussions of the thread, it seems we
> > > reach an agreement on using hypercall to tell DOM0 the grant table info
> > > and event channel irq. Right?
> > 
> > People have different opinion on what should be the way to boot DOM0
> > with ACPI on ARM. A design document would help here to understand what
> > are the possibilities to boot DOM0 (i.e hypercall based, XENV...) and
> > which one would be the most suitable for ARM.
> 
> As I wrote previously
> (http://marc.info/?i=alpine.DEB.2.02.1505291102390.8130%40kaball.uk.xensource.com),
> although I prefer tables, I am OK with hypercalls too, and for the sake
> of moving this work forward in the quickest way possible, let's just do
> that. This is a minor point on the grand scheme of things.
> 
> I suggest you introduce two new hvm params to get the grant table
> address and event channel ppi, see xen/include/public/hvm/params.h. They
> can be retrieved using the HVMOP_get_param hypercall.
> 
> Also remember that if we avoid the XENV table, then we need to set the
> new FADT field "Hypervisor Vendor Identity" appropriately to advertise
> the presence of Xen on the platform.

To be clear, my suggestions are for the design document mentioned below.
I think it is a good idea to send out the design doc first and wait for
Jan's Ack on it, before starting to code anything.


> > >> 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.
> > >>
> > > 
> > > Ok, it's good to reach an agreement before action.
> > > 
> > >> 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.
> > >>
> > > 
> > > Which boot protocol? Could you point it out? Thanks. :)
> > 
> > The way to boot DOM0 with ACPI. There is a page on the Linaro wiki [1],
> > but the content is quite out of date now.
> > 
> > Regards,
> > 
> > [1] https://wiki.linaro.org/LEG/Engineering/Virtualization/ACPI_on_Xen
> 
> http://marc.info/?i=1431893048-5214-1-git-send-email-parth.dixit%40linaro.org
> is a good start, but it needs more details. The important thing to clear
> out is which information is passed to Dom0 and how, because it will
> become a supported external interface going forward.
> 
> Specifically:
> - what information is passed via the small device tree to dom0 and in
>   what format
> - how the acpi tables are given to dom0
>   * mapped or copied?
>   * how do we pass a pointer to them to the kernel?
> - if some tables are changed by Xen before passing them on, it would be
>   good to list what was changed
>   * what tables have been modified
>   * what tables have been added
>   * what tables have been removed
> - how is the memory map passed to Dom0
>   * how do we find out the list of MMIO regions, both temporary and
>     future solutions
>   * how to we tell dom0 where they are
> 

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

[Ian Campbell]

On Fri, 2015-07-31 at 17:24 +0100, Stefano Stabellini wrote:
> 
> One more solution that I would like to see investigated, would be to use
> an hypercall from Dom0 to request MMIO region mappings, after Linux
> completed parsing the DSDT. If we can do this cleanly in Linux, it would
> be our best option.

This would be my preferred option, over both faulting in on data abort and
mapping the whole address space at start of day which are the other two
options which I think we can see for an UEFI+ACPI system.

Sadly the best option "firmware gives us the full address map" is not on
the table with UEFI+ACPI, which is a shame, but oh well.

>   Linux would have to go through all the MMIO regions
> and issue an hypercall for each of them to map it.

> 
> The hypercall could be XENMEM_add_to_physmap, but we would have to add a
> new XENMAPSPACE type to be able to specify an MMIO region as argument.
> See xen/include/public/memory.h.
> 
> I am not sure where is the best place to issue the hypercall in the
> Linux kernel. Perhaps it is possible to list all the registered MMIO
> regions somehow. Or perhaps we could use one of the
> bus_register_notifiers, like we already do for PCI devices, see
> drivers/xen/pci.c. I know that bus_register_notifier can be used with
> AMBA and platform buses too.

FWIW I think an approach based around things happening when entities
(busses, devices etc) are registered with the device model core and
callbacks/hooks on those events would be preferable to trying to get a full
list of all MMIO at some point in time, assume that it is
possible/clean/etc from the guest side...

Ian.

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

[Christoffer Dall]

On Fri, Jul 31, 2015 at 4:09 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:

[...]

>
>
> One option going forward is to map MMIO regions in Dom0 on demand when
> trapping in Xen with a data abort. Specifically in
> xen/arch/arm/traps.c:do_trap_data_abort_guest we could check that the
> guest is dom0 and that the address correspond to a non-ram region not
> owned by Xen. If the checks succeed then we map the page in Dom0.
>
>

I seem to remember people raising issues about mapping device memory
on-demand on KVM/arm64, because you can have weird timing issues
happening if a register map spans multiple pages etc., but i can't
seem to find the original e-mail.  I think it was Ard/Marc/Peter
discussing this.


[...]

>> >>
>> >
>> > Which boot protocol? Could you point it out? Thanks. :)
>>
>> The way to boot DOM0 with ACPI. There is a page on the Linaro wiki [1],
>> but the content is quite out of date now.
>>
>> Regards,
>>
>> [1] https://wiki.linaro.org/LEG/Engineering/Virtualization/ACPI_on_Xen
>
> http://marc.info/?i=1431893048-5214-1-git-send-email-parth.dixit%40linaro.org
> is a good start, but it needs more details. The important thing to clear
> out is which information is passed to Dom0 and how, because it will
> become a supported external interface going forward.
>
> Specifically:
> - what information is passed via the small device tree to dom0 and in
>   what format
> - how the acpi tables are given to dom0
>   * mapped or copied?
>   * how do we pass a pointer to them to the kernel?
> - if some tables are changed by Xen before passing them on, it would be
>   good to list what was changed
>   * what tables have been modified
>   * what tables have been added
>   * what tables have been removed
> - how is the memory map passed to Dom0
>   * how do we find out the list of MMIO regions, both temporary and
>     future solutions
>   * how to we tell dom0 where they are

Also, is there going to be some paravirtualized interface for the info
that systems would normally get from UEFI, or are we going to emulate
UEFI, or is all this going to be in the small DT?

(I know this has been discussed before, but I have forgotten the conclusions)

-Christoffer

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

[Shannon Zhao]

On 2015/7/31 2:02, Parth Dixit wrote:
> Hi Shannon,
>                     instead of getting mmio information for individual
> devices from dsdt, we will map all the non-ram regions described in
> uefi. 
Yes, I don't want to use AML interpreter either. But how to get all the
non-ram regions?

> 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 <shannon.zhao@linaro.org> wrote:
>>
>>
>> On 2015/7/5 21:30, Parth Dixit wrote:
>>> +shannon
>>>
>>> On 15 June 2015 at 06:49, Julien Grall <julien.grall@citrix.com> wrote:
>>>> Hi Parth,
>>>>
>>>> On 14/06/2015 11:27, Parth Dixit wrote:
>>>>>
>>>>> On 8 June 2015 at 22:20, Julien Grall <julien.grall@citrix.com> 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

-- 
Shannon

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

[Parth Dixit]

Map acpi tables described in uefi table to DOM0 address space

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>   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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 22:24, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
>> ---
>>   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

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

[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 <parth.dixit@linaro.org>
---
 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 <xen/errno.h>
 #include <xen/device_tree.h>
 #include <xen/acpi.h>
+#include <acpi/actables.h>
 #include <xen/efi.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/guest_access.h>
@@ -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 = 0x00000010000000;
+    xenv->gnt_size = 0x20000;
+    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_address = tbl_add[TBL_XSDT].start;
+    acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp) );
+
+    /* map rsdp table */
     size = sizeof(struct acpi_table_rsdp);
 
     res = map_regions(d,
-- 
1.9.1

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

[Parth Dixit]

+shannon

On 18 May 2015 at 01:34, Parth Dixit <parth.dixit@linaro.org> 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 <parth.dixit@linaro.org>
> ---
>  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 <xen/errno.h>
>  #include <xen/device_tree.h>
>  #include <xen/acpi.h>
> +#include <acpi/actables.h>
>  #include <xen/efi.h>
>  #include <xen/libfdt/libfdt.h>
>  #include <xen/guest_access.h>
> @@ -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 = 0x00000010000000;
> +    xenv->gnt_size = 0x20000;
> +    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_address = tbl_add[TBL_XSDT].start;
> +    acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp) );
> +
> +    /* map rsdp table */
>      size = sizeof(struct acpi_table_rsdp);
>
>      res = map_regions(d,
> --
> 1.9.1
>

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

[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 <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 22:29, Julien Grall <julien.grall@citrix.com> 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

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

[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 <parth.dixit@linaro.org>
---
 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, sizeof(struct acpi_table_rsdp) );
 
+    prepare_efi_table(d, kinfo, tbl_add);
     /* map rsdp table */
     size = sizeof(struct acpi_table_rsdp);
 
-- 
1.9.1

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

[Parth Dixit]

+shannon

On 18 May 2015 at 01:34, Parth Dixit <parth.dixit@linaro.org> 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 <parth.dixit@linaro.org>
> ---
>  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, sizeof(struct acpi_table_rsdp) );
>
> +    prepare_efi_table(d, kinfo, tbl_add);
>      /* map rsdp table */
>      size = sizeof(struct acpi_table_rsdp);
>
> --
> 1.9.1
>

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

[Parth Dixit]

ACPI will be disabled by default. Define new
command line parameter "acpi" for enabling it.

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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

Re: [PATCH v2 37/41] arm : acpi add acpi parameter to enable/disable acpi

[Julien Grall]

Hi Parth,

On 17/05/2015 21:04, Parth Dixit wrote:
> ACPI will be disabled by default. Define new
> command line parameter "acpi" for enabling it.

I don't think this is right. We have to be able to boot platform where 
there is only ACPI provided without adding a command line option.

Overall, it would be better if we follow the same behavior as Linux i.e 
ACPI is enabled instead off DT unless:
	- ACPI has been disabled (acpi=off)
	- the DT is not empty (it has more than just a /chosen node) and ACPI 
has not been forced enabled (acpi=force).

Regards,

-- 
Julien Grall

Re: [PATCH v2 37/41] arm : acpi add acpi parameter to enable/disable acpi

[Julien Grall]

Hi Parth,

On 17/05/2015 16:04, Parth Dixit wrote:
> +#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);

This acpi_param is never used within this series. Please drop it.

> +    /* Interpret the parameter for use within Xen. */
> +    if ( !parse_bool(s) )
> +    {
> +        disable_acpi();
> +    }
> +    else if ( !strcmp(s, "force") )
> +    {
> +        acpi_disabled = 0;
> +    }
> +}
> +#endif
> +

Regards,

-- 
Julien Grall

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

[Parth Dixit]

efi should be enabled to fetch the root pointer from uefi

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
 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 <asm/setup.h>
 #include <xsm/xsm.h>
 #include <asm/acpi.h>
+#include <xen/efi.h>
 
 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 <asm/i387.h>
 # include <asm/xstate.h>
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 <xen/types.h>
 #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

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

[Jan Beulich]

>>> On 17.05.15 at 22:04, <parth.dixit@linaro.org> 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 <xen/types.h>
>  #endif
>  
> -extern const bool_t efi_enabled;
> +extern bool_t efi_enabled;

Doesn't this break the x86 build?

Jan

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

[Parth Dixit]

+shannon

On 20 May 2015 at 21:57, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 17.05.15 at 22:04, <parth.dixit@linaro.org> 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 <xen/types.h>
>>  #endif
>>
>> -extern const bool_t efi_enabled;
>> +extern bool_t efi_enabled;
>
> Doesn't this break the x86 build?
>
> Jan
>

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

[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 <parth.dixit@linaro.org>
---
 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 <xen/irq.h>
 #include <xen/sched.h>
 #include <xen/perfc.h>
+#include <xen/acpi.h>
 
 #include <asm/current.h>
 
@@ -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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>   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 <xen/irq.h>
>   #include <xen/sched.h>
>   #include <xen/perfc.h>
> +#include <xen/acpi.h>
>
>   #include <asm/current.h>
>
> @@ -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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 23:09, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
>> ---
>>   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 <xen/irq.h>
>>   #include <xen/sched.h>
>>   #include <xen/perfc.h>
>> +#include <xen/acpi.h>
>>
>>   #include <asm/current.h>
>>
>> @@ -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

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

[Parth Dixit]

From: Naresh Bhat <naresh.bhat@linaro.org>

Add ACPI support on arm64 xen hypervisor.

Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
 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

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

[Parth Dixit]

+shannon

On 18 May 2015 at 01:34, Parth Dixit <parth.dixit@linaro.org> wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Add ACPI support on arm64 xen hypervisor.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
>  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
>

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

[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 <parth.dixit@linaro.org>
---
 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

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

[Julien Grall]

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 <parth.dixit@linaro.org>
> ---
>   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

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

[Parth Dixit]

+shannon

On 8 June 2015 at 23:14, Julien Grall <julien.grall@citrix.com> 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 <parth.dixit@linaro.org>
>> ---
>>   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

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

[Julien Grall]

Hi Parth,

Thank you for the patch series.

On 17/05/2015 21:03, Parth Dixit wrote:
> This patch series adds ACPI support for arm64.
> Xen reads static tables described by ACPI standard (5.1) from uefi
> and configures timer, gic and uart. ACPI tables are modified to
> enable PSCI, HVC and xen specific information (grant table and
> event channel interrupts) and mapped into dom0 address space.
> A skeleton device tree is created to pass efi table which contains
> memory layout (which cannot be passed using ACPI) and rsdp pointer to DOM0.
> DOM0 parses dynamic ACPI tables and configure other peripherals.
>
> Patches 1-21 add ACPI support for xen/uefi interface
> Patches 22-41 add ACPI support for xen/Dom0 interface
> Last patch "xen: arm64: Add ACPI support" enables the support for ACPI
> so that individual patches do not affect working xen code base.
>
> Patches are tested on FVP base model and same binary is working for ACPI as well as
> device tree.(32 bit is not tested).

I will give a try on 32 bits when I will review the patches.

> ACPI is now configurable via commandline option "acpi".
> To boot from ACPI this parameter should be set to "force".

Wouldn't it be possible to detect automatically if we need to use ACPI 
or not? IIRC it's what Linux does.

> Instructions for reproducing the setup and working code base can be found
> in the following repositories
> wiki : https://wiki.linaro.org/LEG/Engineering/Xen_boot_on_FVP_ACPI_UEFI
> linux : https://git.linaro.org/people/parth.dixit/xen-upstreaming/leg-kernel.git

Linux 4.1 has ACPI support for ARM64. What are the missing parts in 
order to use upstream Linux as DOM0?  What's the plan to upstream them?

> Few workarounds have been made to get it working, these are as follows
> 1. In Xen interrupts are routed at the boot time with edge/trigger level set to 0
> because this information is not available at the time of booting.

edge/trigger is only a bit. Can't you just avoid to set it rather than 
using a potentially incorrect value?

> 2. EFI runtime services are disaled in linux but proper solution has to come from linux side.

Can you details a bit more? What is missing?

Regards,

-- 
Julien Grall

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

[Julien Grall]

Hi Parth

(You dropped xen-devel, re-cc it)

On 18/05/15 10:59, Parth Dixit wrote:
> yes i tested with linux-next of 15th may and it is working fine with
> it,except mounting of root partiton because kernel is not able to
> detetct the partition
> i did not looked further into it but its presumably configuration of
> right driver.
> Linux mainline will need 3 additional patches
> 1. Adding STAO and XENV
> 2. Hiding of UART
> 3. Enabling xen compilation with ACPI which was disabled by Hanjun.
> I'll wait for comment's on this series and if there are no major changes
> i'll cleanup linux patches and send them for review as well.

I think you can send an RFC now. The STA0 and XENV table are
well-defined and the rest of the patches doesn't seem to be tight with
your Xen series.

> 
> 
>         Few workarounds have been made to get it working, these are as
>         follows
>         1. In Xen interrupts are routed at the boot time with
>         edge/trigger level set to 0
>         because this information is not available at the time of booting.
> 
> 
>     edge/trigger is only a bit. Can't you just avoid to set it rather
>     than using a potentially incorrect value?
> 
> That would require disabling the checks for edge/trigger at multiple
> places for acpi, if you are ok with the approach
> i'll go ahead and send the patch.

IIRC, during the last Linaro connect we agreed to differ edge/trigger
setting for IRQ assigned to a Domain for both ACPI and DT.

> 
>         2. EFI runtime services are disaled in linux but proper solution
>         has to come from linux side.
> 
> 
>     Can you details a bit more? What is missing?
> 
> We only create EFI stub for passing RSDP and memory data in xen, we are
> not implementing full fledged runtime service support
> for EFI. At present linux expects that if EFI interface is present
> runtime services are also available.

Thanks for the explanation. Please add it in the next cover letter. It's
useful for people who weren't present at the meeting or forgot what was
said.

Regards,

-- 
Julien Grall

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

[Jan Beulich]

>>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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

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

[Parth Dixit]

[-- Attachment #1.1: Type: text/plain, Size: 2628 bytes --]

On 18 May 2015 at 13:55, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.05.15 at 22:03, <parth.dixit@linaro.org> 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

[-- Attachment #1.2: Type: text/html, Size: 3560 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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