Re: [Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-04-02 Thread Ian Campbell 
On Thu, 2015-04-02 at 13:55 +0530, Vijay Kilari wrote:
 On Wed, Apr 1, 2015 at 5:04 PM, Ian Campbell ian.campb...@citrix.com wrote:
  On Thu, 2015-03-19 at 20:07 +0530, vijay.kil...@gmail.com wrote:
  From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
 
  This patch just makes ITS driver taken from linux
  compiles in xen environment.
 
  What is your intention wrt future updates to this driver?
 
  Are you intending to keep things in sync and import things from the
  Linux side (similar to the smmu drviers) or are you taking the Linux
  code as a starting point and intending that it then be maintained
  independently as a Xen driver from then on?
 
 Yes, I intend to keep things in sync with Linux driver.
 I have kept most the code same as Linux side except removing unused code.

There is a tonne of changes going on if that is your goal, in particular
in this patch but also in some of the following refactoring patches.
When this series is over it seems like the driver would bear very little
resemblance to the Linux one.

If you want to go this route then to aid in future synchronisation from
Linux patches the goal should be to make the changes to the Linux code
as minimal as possible, by defining shim functions and typedefs etc at
the top of the file, e.g. as Julien has tried to do with the smmu
driver.

Unlike the smmu stuff, which has a reasonably small and well-defined
interface to the kernel which can be easily shimmed between Xen and
Linux it's not clear to me that this approach is workable for ITS, the
Xen and Linux interrupt handling systems are rather different and ITS
needs to be more tightly integrated with other bits of Xen, in
particular the GIC drivers.

However if you think maintaining something which can be synchronised
from Linux is viable and desirable then that's ok by me.

Ian.


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

Re: [Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-04-02 Thread Vijay Kilari 
On Wed, Apr 1, 2015 at 5:04 PM, Ian Campbell ian.campb...@citrix.com wrote:
 On Thu, 2015-03-19 at 20:07 +0530, vijay.kil...@gmail.com wrote:
 From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com

 This patch just makes ITS driver taken from linux
 compiles in xen environment.

 What is your intention wrt future updates to this driver?

 Are you intending to keep things in sync and import things from the
 Linux side (similar to the smmu drviers) or are you taking the Linux
 code as a starting point and intending that it then be maintained
 independently as a Xen driver from then on?

Yes, I intend to keep things in sync with Linux driver.
I have kept most the code same as Linux side except removing unused code.

Regards
Vijay

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

Re: [Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-04-02 Thread Vijay Kilari 
On Thu, Apr 2, 2015 at 2:55 PM, Ian Campbell ian.campb...@citrix.com wrote:
 On Thu, 2015-04-02 at 13:55 +0530, Vijay Kilari wrote:
 On Wed, Apr 1, 2015 at 5:04 PM, Ian Campbell ian.campb...@citrix.com wrote:
  On Thu, 2015-03-19 at 20:07 +0530, vijay.kil...@gmail.com wrote:
  From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
 
  This patch just makes ITS driver taken from linux
  compiles in xen environment.
 
  What is your intention wrt future updates to this driver?
 
  Are you intending to keep things in sync and import things from the
  Linux side (similar to the smmu drviers) or are you taking the Linux
  code as a starting point and intending that it then be maintained
  independently as a Xen driver from then on?

 Yes, I intend to keep things in sync with Linux driver.
 I have kept most the code same as Linux side except removing unused code.

 There is a tonne of changes going on if that is your goal, in particular
 in this patch but also in some of the following refactoring patches.
 When this series is over it seems like the driver would bear very little
 resemblance to the Linux one.

 If you want to go this route then to aid in future synchronisation from
 Linux patches the goal should be to make the changes to the Linux code
 as minimal as possible, by defining shim functions and typedefs etc at
 the top of the file, e.g. as Julien has tried to do with the smmu
 driver.

 Unlike the smmu stuff, which has a reasonably small and well-defined
 interface to the kernel which can be easily shimmed between Xen and
 Linux it's not clear to me that this approach is workable for ITS, the
 Xen and Linux interrupt handling systems are rather different and ITS
 needs to be more tightly integrated with other bits of Xen, in
 particular the GIC drivers.

Yes, there is lot of unnecessary code for Xen in ITS driver which is
trimmed down. However the whatever functions that are used are retained,
So that changes made to Linux driver can be easily mapped to ITS driver.

IMO, We can create macros from debug prints, memory allocation  cache mgmt
apis, that only reduces changes we make.


 However if you think maintaining something which can be synchronised
 from Linux is viable and desirable then that's ok by me.

Regards
Vijay

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

Re: [Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-04-02 Thread Julien Grall 

Hi Vijay,

On 02/04/2015 09:25, Vijay Kilari wrote:

On Wed, Apr 1, 2015 at 5:04 PM, Ian Campbell ian.campb...@citrix.com wrote:

On Thu, 2015-03-19 at 20:07 +0530, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com

This patch just makes ITS driver taken from linux
compiles in xen environment.


What is your intention wrt future updates to this driver?

Are you intending to keep things in sync and import things from the
Linux side (similar to the smmu drviers) or are you taking the Linux
code as a starting point and intending that it then be maintained
independently as a Xen driver from then on?


Yes, I intend to keep things in sync with Linux driver.
I have kept most the code same as Linux side except removing unused code.



The result of this series shows that we diverge a lot from the original 
driver. We have lots of Xen specific code added and some interface has 
changed for our purpose.


For instance, removing unused code is not something we should do in sync 
driver because it's harder to backport patch (the context of the diff 
will unlikely be the same).


Furthermore, we may also want to change the way that completion is 
notified (see discussion on patch #13).


While it was a good thing to keep the SMMU driver sync with Linux (not 
much diff required), I think this would be a mistake for the ITS.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-03-23 Thread Julien Grall 
On 23/03/15 12:24, Vijay Kilari wrote:
   /*
* ITS command descriptors - parameters to be encoded in a command
 @@ -228,10 +243,10 @@ static struct its_collection
 *its_build_mapd_cmd(struct its_cmd_block *cmd,
  struct its_cmd_desc
 *desc)
   {
 unsigned long itt_addr;
 -   u8 size = ilog2(desc-its_mapd_cmd.dev-nr_ites);
 +   u8 size = max(fls(desc-its_mapd_cmd.dev-nr_ites) - 1, 1);


 ilog2 on an uint32_t is defined as fls(val) - 1. Where does the max come
 from?

 IHMO, I would define ilog2 in Xen, that would be easier.
 
 Anyway this code is not used later. So I don't bother much about this

Again, what's the purpose of fixing compilation bug in code which will
be remove a patch later?

If you want to fix build errors, you have to fix them correctly. Not
trying to add wrong code in order to make the compiler happy...



 -   itt_addr = virt_to_phys(desc-its_mapd_cmd.dev-itt);
 -   itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN);
 +   itt_addr = __pa(desc-its_mapd_cmd.dev-itt);
 +itt_addr = ROUNDUP(itt_addr, ITS_ITT_ALIGN);


 This file use the Linux coding style. Please use hard tab.


 its_encode_cmd(cmd, GITS_CMD_MAPD);
 its_encode_devid(cmd, desc-its_mapd_cmd.dev-device_id);
 @@ -348,7 +363,7 @@ static struct its_cmd_block *its_allocate_entry(struct
 its_node *its)
 while (its_queue_full(its)) {
 count--;
 if (!count) {
 -   pr_err_ratelimited(ITS queue not draining\n);
 +   its_err(ITS queue not draining\n);


 its_err and pr_err_ratelimited are not the same things. The former is not
 ratelimited.

 AFAICT this function will be accessible in someway from the guest. It would
 be possible to DOS Xen when sending a command.
 
 Any equivalent ratelimited function in Xen?

All GUEST_* and INFO/DEBUG are ratelimited. It might be worth to
introduce ratelimited concept for ERROR.


 return NULL;
 }
 cpu_relax();
 @@ -380,7 +395,7 @@ static void its_flush_cmd(struct its_node *its, struct
 its_cmd_block *cmd)
  * the ITS.
  */
 if (its-flags  ITS_FLAGS_CMDQ_NEEDS_FLUSHING)
 -   __flush_dcache_area(cmd, sizeof(*cmd));
 +   clean_and_invalidate_dcache_va_range(cmd, sizeof(*cmd));
 else
 dsb(ishst);
   }
 @@ -402,7 +417,7 @@ static void its_wait_for_range_completion(struct
 its_node *its,

 count--;
 if (!count) {
 -   pr_err_ratelimited(ITS queue timeout\n);
 +   its_err(ITS queue timeout\n);


 Ditto

 [..]

 -static void its_send_inv(struct its_device *dev, u32 event_id)
 +/* TODO: Remove static for the sake of compilation */
 +void its_send_inv(struct its_device *dev, u32 event_id)


 Rather than changing the prototype. Would it be possible to #if 0 the
 function? It would be easier to keep track change.
 
 Does not matter much. Anyway I can try as you wish

Depend if you care about the reviewers time or not...

 

 -static int its_alloc_device_irq(struct its_device *dev, irq_hw_number_t
 *hwirq)
 +/* TODO: Remove static for the sake of compilation */
 +int its_alloc_device_irq(struct its_device *dev, int *hwirq)
   {
 int idx;

 @@ -1139,6 +1169,8 @@ static int its_alloc_device_irq(struct its_device
 *dev, irq_hw_number_t *hwirq)
 return 0;
   }

 +/* pci and msi handling no more required here */


 Hmmm why?
 
 This code is not required. we don't have msi_domain_ops

I have the feeling that counting the number of MSI for a device will be
useful later.

 


 Already said on V1: of_device_id and dt_device_match are compatible. If you
 change the name it will work too...

 +   while ((np = dt_find_matching_node(np, its_device_ids)))
 +   {
 +   if (!dt_find_property(np, msi-controller, NULL))
 +   continue;


 In your cover letter, you said you support multiple ITS node but this piece
 of code show that it's not the case...
 
If I remember  correctly, this is later updated

Unfortunately not... anyway the for loop is valid. So please drop your
while here.



 +   }

 -   for (np = of_find_matching_node(node, its_device_id); np;
 -np = of_find_matching_node(np, its_device_id)) {
 -   its_probe(np, parent_domain);


 The for loop was perfect, why did you drop it?

 +   if (np) {
 +   its_probe(np);
 }

 if (list_empty(its_nodes)) {
 -   pr_warn(ITS: No ITS available, not enabling LPIs\n);
 +   its_warn(ITS: No ITS available, not enabling LPIs\n);
 return -ENXIO;
 }

 diff --git a/xen/include/asm-arm/gic_v3_defs.h
 b/xen/include/asm-arm/gic_v3_defs.h
 index 4e64b56..f8bac52 100644
 --- a/xen/include/asm-arm/gic_v3_defs.h
 +++ b/xen/include/asm-arm/gic_v3_defs.h
 @@ -59,11 +59,12

Re: [Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-03-23 Thread Vijay Kilari 
Hi Julien,

On Fri, Mar 20, 2015 at 8:36 PM, Julien Grall julien.gr...@linaro.org wrote:
 Hello Vijay,

 On 19/03/2015 14:37, vijay.kil...@gmail.com wrote:

   static LIST_HEAD(its_nodes);
   static DEFINE_SPINLOCK(its_lock);
 -static struct device_node *gic_root_node;
 -static struct rdists *gic_rdists;
 +static struct dt_device_node *gic_root_node;
 +static struct rdist_prop  *gic_rdists;

 -#define gic_data_rdist()   (raw_cpu_ptr(gic_rdists-rdist))
 -#define gic_data_rdist_rd_base()   (gic_data_rdist()-rd_base)
 +#define gic_data_rdist()   (per_cpu(rdist,
 smp_processor_id()))


 Again why didn't you return a pointer here? It would have been avoid some
 confusing changes (s/-/./) in the code.

 #define gic_data_rdist(per_cpu(rdist, smp_processor_id))

 +#define gic_data_rdist_rd_base()   (per_cpu(rdist,
 smp_processor_id()).rbase)


 That would avoid this change too.

OK. Let me try



   /*
* ITS command descriptors - parameters to be encoded in a command
 @@ -228,10 +243,10 @@ static struct its_collection
 *its_build_mapd_cmd(struct its_cmd_block *cmd,
  struct its_cmd_desc
 *desc)
   {
 unsigned long itt_addr;
 -   u8 size = ilog2(desc-its_mapd_cmd.dev-nr_ites);
 +   u8 size = max(fls(desc-its_mapd_cmd.dev-nr_ites) - 1, 1);


 ilog2 on an uint32_t is defined as fls(val) - 1. Where does the max come
 from?

 IHMO, I would define ilog2 in Xen, that would be easier.

Anyway this code is not used later. So I don't bother much about this



 -   itt_addr = virt_to_phys(desc-its_mapd_cmd.dev-itt);
 -   itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN);
 +   itt_addr = __pa(desc-its_mapd_cmd.dev-itt);
 +itt_addr = ROUNDUP(itt_addr, ITS_ITT_ALIGN);


 This file use the Linux coding style. Please use hard tab.


 its_encode_cmd(cmd, GITS_CMD_MAPD);
 its_encode_devid(cmd, desc-its_mapd_cmd.dev-device_id);
 @@ -348,7 +363,7 @@ static struct its_cmd_block *its_allocate_entry(struct
 its_node *its)
 while (its_queue_full(its)) {
 count--;
 if (!count) {
 -   pr_err_ratelimited(ITS queue not draining\n);
 +   its_err(ITS queue not draining\n);


 its_err and pr_err_ratelimited are not the same things. The former is not
 ratelimited.

 AFAICT this function will be accessible in someway from the guest. It would
 be possible to DOS Xen when sending a command.

Any equivalent ratelimited function in Xen?


 return NULL;
 }
 cpu_relax();
 @@ -380,7 +395,7 @@ static void its_flush_cmd(struct its_node *its, struct
 its_cmd_block *cmd)
  * the ITS.
  */
 if (its-flags  ITS_FLAGS_CMDQ_NEEDS_FLUSHING)
 -   __flush_dcache_area(cmd, sizeof(*cmd));
 +   clean_and_invalidate_dcache_va_range(cmd, sizeof(*cmd));
 else
 dsb(ishst);
   }
 @@ -402,7 +417,7 @@ static void its_wait_for_range_completion(struct
 its_node *its,

 count--;
 if (!count) {
 -   pr_err_ratelimited(ITS queue timeout\n);
 +   its_err(ITS queue timeout\n);


 Ditto

 [..]

 -static void its_send_inv(struct its_device *dev, u32 event_id)
 +/* TODO: Remove static for the sake of compilation */
 +void its_send_inv(struct its_device *dev, u32 event_id)


 Rather than changing the prototype. Would it be possible to #if 0 the
 function? It would be easier to keep track change.

Does not matter much. Anyway I can try as you wish


 -static int its_alloc_device_irq(struct its_device *dev, irq_hw_number_t
 *hwirq)
 +/* TODO: Remove static for the sake of compilation */
 +int its_alloc_device_irq(struct its_device *dev, int *hwirq)
   {
 int idx;

 @@ -1139,6 +1169,8 @@ static int its_alloc_device_irq(struct its_device
 *dev, irq_hw_number_t *hwirq)
 return 0;
   }

 +/* pci and msi handling no more required here */


 Hmmm why?

This code is not required. we don't have msi_domain_ops



 Already said on V1: of_device_id and dt_device_match are compatible. If you
 change the name it will work too...

 +   while ((np = dt_find_matching_node(np, its_device_ids)))
 +   {
 +   if (!dt_find_property(np, msi-controller, NULL))
 +   continue;


 In your cover letter, you said you support multiple ITS node but this piece
 of code show that it's not the case...

   If I remember  correctly, this is later updated

 +   }

 -   for (np = of_find_matching_node(node, its_device_id); np;
 -np = of_find_matching_node(np, its_device_id)) {
 -   its_probe(np, parent_domain);


 The for loop was perfect, why did you drop it?

 +   if (np) {
 +   its_probe(np);
 }

 if (list_empty(its_nodes)) {
 -   pr_warn(ITS: No ITS available, not enabling LPIs\n);
 +

Re: [Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-03-20 Thread Julien Grall 

Hello Vijay,

On 19/03/2015 14:37, vijay.kil...@gmail.com wrote:

  static LIST_HEAD(its_nodes);
  static DEFINE_SPINLOCK(its_lock);
-static struct device_node *gic_root_node;
-static struct rdists *gic_rdists;
+static struct dt_device_node *gic_root_node;
+static struct rdist_prop  *gic_rdists;

-#define gic_data_rdist()   (raw_cpu_ptr(gic_rdists-rdist))
-#define gic_data_rdist_rd_base()   (gic_data_rdist()-rd_base)
+#define gic_data_rdist()   (per_cpu(rdist, smp_processor_id()))


Again why didn't you return a pointer here? It would have been avoid 
some confusing changes (s/-/./) in the code.


#define gic_data_rdist(per_cpu(rdist, smp_processor_id))


+#define gic_data_rdist_rd_base()   (per_cpu(rdist, 
smp_processor_id()).rbase)


That would avoid this change too.



  /*
   * ITS command descriptors - parameters to be encoded in a command
@@ -228,10 +243,10 @@ static struct its_collection *its_build_mapd_cmd(struct 
its_cmd_block *cmd,
 struct its_cmd_desc *desc)
  {
unsigned long itt_addr;
-   u8 size = ilog2(desc-its_mapd_cmd.dev-nr_ites);
+   u8 size = max(fls(desc-its_mapd_cmd.dev-nr_ites) - 1, 1);


ilog2 on an uint32_t is defined as fls(val) - 1. Where does the max come 
from?


IHMO, I would define ilog2 in Xen, that would be easier.



-   itt_addr = virt_to_phys(desc-its_mapd_cmd.dev-itt);
-   itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN);
+   itt_addr = __pa(desc-its_mapd_cmd.dev-itt);
+itt_addr = ROUNDUP(itt_addr, ITS_ITT_ALIGN);


This file use the Linux coding style. Please use hard tab.



its_encode_cmd(cmd, GITS_CMD_MAPD);
its_encode_devid(cmd, desc-its_mapd_cmd.dev-device_id);
@@ -348,7 +363,7 @@ static struct its_cmd_block *its_allocate_entry(struct 
its_node *its)
while (its_queue_full(its)) {
count--;
if (!count) {
-   pr_err_ratelimited(ITS queue not draining\n);
+   its_err(ITS queue not draining\n);


its_err and pr_err_ratelimited are not the same things. The former is 
not ratelimited.


AFAICT this function will be accessible in someway from the guest. It 
would be possible to DOS Xen when sending a command.



return NULL;
}
cpu_relax();
@@ -380,7 +395,7 @@ static void its_flush_cmd(struct its_node *its, struct 
its_cmd_block *cmd)
 * the ITS.
 */
if (its-flags  ITS_FLAGS_CMDQ_NEEDS_FLUSHING)
-   __flush_dcache_area(cmd, sizeof(*cmd));
+   clean_and_invalidate_dcache_va_range(cmd, sizeof(*cmd));
else
dsb(ishst);
  }
@@ -402,7 +417,7 @@ static void its_wait_for_range_completion(struct its_node 
*its,

count--;
if (!count) {
-   pr_err_ratelimited(ITS queue timeout\n);
+   its_err(ITS queue timeout\n);


Ditto

[..]


-static void its_send_inv(struct its_device *dev, u32 event_id)
+/* TODO: Remove static for the sake of compilation */
+void its_send_inv(struct its_device *dev, u32 event_id)


Rather than changing the prototype. Would it be possible to #if 0 the 
function? It would be easier to keep track change.



  {
struct its_cmd_desc desc;

@@ -479,7 +495,8 @@ static void its_send_mapc(struct its_node *its, struct 
its_collection *col,
its_send_single_command(its, its_build_mapc_cmd, desc);
  }

-static void its_send_mapvi(struct its_device *dev, u32 irq_id, u32 id)
+/* TODO: Remove static for the sake of compilation */
+void its_send_mapvi(struct its_device *dev, u32 irq_id, u32 id)


Ditto and same for all those kind of changes.

[..]


-static unsigned long *its_lpi_alloc_chunks(int nr_irqs, int *base, int *nr_ids)
+static unsigned long *its_lpi_alloc_chunks(int nirqs, int *base, int *nr_ids)


This is because nr_irqs is a define on ARM, rigth? If so, I would prefer 
to define nr_irqs as a variable.


[..]


  /*
@@ -745,31 +769,31 @@ static void its_lpi_free(unsigned long *bitmap, int base, 
int nr_ids)
  /*
   * This is how many bits of ID we need, including the useless ones.
   */
-#define LPI_NRBITS ilog2(LPI_PROPBASE_SZ + SZ_8K)
+#define LPI_NRBITS fls(LPI_PROPBASE_SZ + SZ_8K) - 1


Missing parenthesis.



  #define LPI_PROP_DEFAULT_PRIO 0xa0


I would either move LPI_PROP_DEFAULT_PRIO in asm-arm/gic.h or define it 
using GIC_PRI_IRQ.


This would allow us to change the priority later without having issue 
with LPI.




  static int __init its_alloc_lpi_tables(void)
  {
-   phys_addr_t paddr;
+   paddr_t paddr;

-   gic_rdists-prop_page = alloc_pages(GFP_NOWAIT,
-  get_order(LPI_PROPBASE_SZ));
+   gic_rdists-prop_page = 
alloc_xenheap_pages(get_order_from_bytes(LPI_PROPBASE_SZ), 0);
if (!gic_rdists-prop_page) {
-   pr_err(Failed to allocate

[Xen-devel] [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen

2015-03-19 Thread vijay . kilari 
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com

This patch just makes ITS driver taken from linux
compiles in xen environment.

The following changes are done
  - memory allocation apis are changed
  - raw spin lock api's changed to normal spin lock api's
  - debug prints changed to xen debug prints
  - remove msi chip functions to setup_irq and teardown_irq
  - linux irqchip functions are removed
  - updated gic_v3_defs.h file

Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v2: - put unused code under #if0/endif
- changes to redistributor is moved to separate patch
- Fixed comments from RFC version
---
 xen/arch/arm/Makefile |1 +
 xen/arch/arm/gic-v3-its.c |  337 +
 xen/include/asm-arm/gic_v3_defs.h |  116 -
 3 files changed, 304 insertions(+), 150 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41aba2e..66ea264 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -31,6 +31,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o vgic-v2.o
 obj-$(CONFIG_ARM_64) += vgic-v3.o
+obj-$(CONFIG_ARM_64) += gic-v3-its.o
 obj-y += vtimer.o
 obj-y += vuart.o
 obj-y += hvm.o
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 596b0a9..ce7ced6 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -2,6 +2,10 @@
  * Copyright (C) 2013, 2014 ARM Limited, All Rights Reserved.
  * Author: Marc Zyngier marc.zyng...@arm.com
  *
+ * Xen changes:
+ * Vijaya Kumar K vijaya.ku...@caviumnetworks.com
+ * Copyright (C) 2014, 2015 Cavium Inc.
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
@@ -15,28 +19,41 @@
  * along with this program.  If not, see http://www.gnu.org/licenses/.
  */
 
-#include linux/bitmap.h
-#include linux/cpu.h
-#include linux/delay.h
-#include linux/interrupt.h
-#include linux/log2.h
-#include linux/mm.h
-#include linux/msi.h
-#include linux/of.h
-#include linux/of_address.h
-#include linux/of_irq.h
-#include linux/of_pci.h
-#include linux/of_platform.h
-#include linux/percpu.h
-#include linux/slab.h
-
-#include linux/irqchip/arm-gic-v3.h
-
-#include asm/cacheflush.h
-#include asm/cputype.h
-#include asm/exception.h
-
-#include irqchip.h
+#include xen/config.h
+#include xen/bitops.h
+#include xen/lib.h
+#include xen/init.h
+#include xen/cpu.h
+#include xen/mm.h
+#include xen/irq.h
+#include xen/sched.h
+#include xen/errno.h
+#include xen/delay.h
+#include xen/device_tree.h
+#include xen/libfdt/libfdt.h
+#include xen/xmalloc.h
+#include xen/list.h
+#include xen/sizes.h
+#include xen/vmap.h
+#include asm/p2m.h
+#include asm/domain.h
+#include asm/io.h
+#include asm/device.h
+#include asm/gic.h
+#include asm/gic_v3_defs.h
+
+#define its_print(lvl, fmt, ...)  \
+   printk(lvl GIC-ITS: fmt, ## __VA_ARGS__)
+
+#define its_err(fmt, ...) its_print(XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define its_dbg(fmt, ...) \
+   its_print(XENLOG_DEBUG, fmt, ## __VA_ARGS__)
+
+#define its_info(fmt, ...)\
+   its_print(XENLOG_INFO, fmt, ## __VA_ARGS__)
+
+#define its_warn(fmt, ...)\
 
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING  (1  0)
 
@@ -58,10 +75,8 @@ struct its_collection {
  * devices writing to it.
  */
 struct its_node {
-   raw_spinlock_t  lock;
+   spinlock_t  lock;
struct list_headentry;
-   struct msi_controller   msi_chip;
-   struct irq_domain   *domain;
void __iomem*base;
unsigned long   phys_base;
struct its_cmd_block*cmd_base;
@@ -85,7 +100,7 @@ struct its_device {
struct its_collection   *collection;
void*itt;
unsigned long   *lpi_map;
-   irq_hw_number_t lpi_base;
+   u32 lpi_base;
int nr_lpis;
u32 nr_ites;
u32 device_id;
@@ -93,11 +108,11 @@ struct its_device {
 
 static LIST_HEAD(its_nodes);
 static DEFINE_SPINLOCK(its_lock);
-static struct device_node *gic_root_node;
-static struct rdists *gic_rdists;
+static struct dt_device_node *gic_root_node;
+static struct rdist_prop  *gic_rdists;
 
-#define gic_data_rdist()   (raw_cpu_ptr(gic_rdists-rdist))
-#define gic_data_rdist_rd_base()   (gic_data_rdist()-rd_base)
+#define gic_data_rdist()   (per_cpu(rdist, smp_processor_id()))
+#define gic_data_rdist_rd_base()   (per_cpu(rdist, 
smp_processor_id()).rbase)
 
 /*
  * ITS command descriptors - parameters to be encoded in a command
@@ -228,10 +243,10 @@ static struct its_collection