Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

2017-08-18 Thread Andre Przywara 
Hi,

On 18/08/17 15:21, Julien Grall wrote:
> 
> 
> On 17/08/17 18:06, Andre Przywara wrote:
>> Hi,
> 
> Hi Andre,
> 
>> On 11/08/17 15:10, Julien Grall wrote:
>>> Hi Andre,
>>> 
>>> On 21/07/17 20:59, Andre Przywara wrote:
 Since the GICs MMIO access always covers a number of IRQs at
 once, introduce wrapper functions which loop over those IRQs,
 take their locks and read or update the priority values. This
 will be used in a later patch.
 
 Signed-off-by: Andre Przywara  --- 
 xen/arch/arm/vgic.c| 37
 + 
 xen/include/asm-arm/vgic.h |  5 + 2 files changed, 42
 insertions(+)
 
 diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index
 434b7e2..b2c9632 100644 --- a/xen/arch/arm/vgic.c +++
 b/xen/arch/arm/vgic.c @@ -243,6 +243,43 @@ static int
 vgic_get_virq_priority(struct vcpu *v, unsigned int virq) 
 return ACCESS_ONCE(rank->priority[virq &
 INTERRUPT_RANK_MASK]); }
 
 +#define MAX_IRQS_PER_IPRIORITYR 4
>>> 
>>> The name gives the impression that you may have IPRIORITYR with
>>> only 1 IRQ. But this is not true. The registers is always 4.
>>> However, you are able to access using byte or word.
>>> 
 +uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int
 nrirqs,
>>> 
>>> I am well aware that the vgic code is mixing between virq and
>>> irq. Moving forward, we should use virq to avoid confusion.
>>> 
 + unsigned int first_irq)
>>> 
>>> Please stay consistent, with the naming. Either nr_irqs/first_irq
>>> or nrirqs/firstirq. But not a mix.
>>> 
>>> Also, it makes more sense to describe first the start then
>>> number.
>>> 
 +{ +struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR]; +
 unsigned long flags; +uint32_t ret = 0, i; + +
 local_irq_save(flags); +vgic_lock_irqs(v, nrirqs,
 first_irq, pirqs);
>>> 
>>> I am not convinced on the usefulness of taking all the locks in
>>> one go. At one point in the time, you only need to lock a given
>>> pending_irq.
>> 
>> I don't think so. The MMIO access a guest does is expected to be
>> atomic, so it expects to read the priorities of the four interrupts
>> as they were *at one point in time*. This issue is more obvious for
>> the enabled bit, for instance, but also here a (32-bit) read and a
>> write of some IPRIORITYR might race against each other. This was
>> covered by the rank lock before, but now we have to bite the bullet
>> and lock all involved IRQs.
> 
> A well-behaved guest would need a lock in order to modify the
> hardware as it can't predict in which order the write will happen. If
> the guest does not respect that I don't think you it is necessary to
> require atomicity of the modification.
> 
> This is making the code more complex for a little benefits and also 
> increase the duration of the interrupt masked.
> 
> So as long as it does not affect the hypervisor, then I think it is
> fine to not handle more than the atomicity at the IRQ level.

Fair enough, I can live with that. I didn't like the added complexity
for the tiny benefit either, just wanted to retain the behaviour we had
naturally with the rank lock before.
So this is definitely true for IPRIORITYR, ICFGR and friends, but I need
to double check on ISENABLER/ICENABLER, because of the OR/AND-NOT
semantics, which allows lockless accesses from the software side. I
believe this is fine, though.

Cheers,
Andre.

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

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

2017-08-18 Thread Julien Grall 



On 17/08/17 18:06, Andre Przywara wrote:

Hi,


Hi Andre,


On 11/08/17 15:10, Julien Grall wrote:

Hi Andre,

On 21/07/17 20:59, Andre Przywara wrote:

Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 37 +
 xen/include/asm-arm/vgic.h |  5 +
 2 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 434b7e2..b2c9632 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -243,6 +243,43 @@ static int vgic_get_virq_priority(struct vcpu *v,
unsigned int virq)
 return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
 }

+#define MAX_IRQS_PER_IPRIORITYR 4


The name gives the impression that you may have IPRIORITYR with only 1
IRQ. But this is not true. The registers is always 4. However, you are
able to access using byte or word.


+uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,


I am well aware that the vgic code is mixing between virq and irq.
Moving forward, we should use virq to avoid confusion.


+ unsigned int first_irq)


Please stay consistent, with the naming. Either nr_irqs/first_irq or
nrirqs/firstirq. But not a mix.

Also, it makes more sense to describe first the start then number.


+{
+struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
+unsigned long flags;
+uint32_t ret = 0, i;
+
+local_irq_save(flags);
+vgic_lock_irqs(v, nrirqs, first_irq, pirqs);


I am not convinced on the usefulness of taking all the locks in one go.
At one point in the time, you only need to lock a given pending_irq.


I don't think so. The MMIO access a guest does is expected to be atomic,
so it expects to read the priorities of the four interrupts as they were
*at one point in time*.
This issue is more obvious for the enabled bit, for instance, but also
here a (32-bit) read and a write of some IPRIORITYR might race against
each other. This was covered by the rank lock before, but now we have to
bite the bullet and lock all involved IRQs.


A well-behaved guest would need a lock in order to modify the hardware 
as it can't predict in which order the write will happen. If the guest 
does not respect that I don't think you it is necessary to require 
atomicity of the modification.


This is making the code more complex for a little benefits and also 
increase the duration of the interrupt masked.


So as long as it does not affect the hypervisor, then I think it is fine 
to not handle more than the atomicity at the IRQ level.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

2017-08-17 Thread Andre Przywara 
Hi,

On 11/08/17 15:10, Julien Grall wrote:
> Hi Andre,
> 
> On 21/07/17 20:59, Andre Przywara wrote:
>> Since the GICs MMIO access always covers a number of IRQs at once,
>> introduce wrapper functions which loop over those IRQs, take their
>> locks and read or update the priority values.
>> This will be used in a later patch.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/vgic.c| 37 +
>>  xen/include/asm-arm/vgic.h |  5 +
>>  2 files changed, 42 insertions(+)
>>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 434b7e2..b2c9632 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -243,6 +243,43 @@ static int vgic_get_virq_priority(struct vcpu *v,
>> unsigned int virq)
>>  return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
>>  }
>>
>> +#define MAX_IRQS_PER_IPRIORITYR 4
> 
> The name gives the impression that you may have IPRIORITYR with only 1
> IRQ. But this is not true. The registers is always 4. However, you are
> able to access using byte or word.
> 
>> +uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,
> 
> I am well aware that the vgic code is mixing between virq and irq.
> Moving forward, we should use virq to avoid confusion.
> 
>> + unsigned int first_irq)
> 
> Please stay consistent, with the naming. Either nr_irqs/first_irq or
> nrirqs/firstirq. But not a mix.
> 
> Also, it makes more sense to describe first the start then number.
> 
>> +{
>> +struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
>> +unsigned long flags;
>> +uint32_t ret = 0, i;
>> +
>> +local_irq_save(flags);
>> +vgic_lock_irqs(v, nrirqs, first_irq, pirqs);
> 
> I am not convinced on the usefulness of taking all the locks in one go.
> At one point in the time, you only need to lock a given pending_irq.

I don't think so. The MMIO access a guest does is expected to be atomic,
so it expects to read the priorities of the four interrupts as they were
*at one point in time*.
This issue is more obvious for the enabled bit, for instance, but also
here a (32-bit) read and a write of some IPRIORITYR might race against
each other. This was covered by the rank lock before, but now we have to
bite the bullet and lock all involved IRQs.

Cheers,
Andre.

>> +
>> +for ( i = 0; i < nrirqs; i++ )
>> +ret |= pirqs[i]->priority << (i * 8);
> 
> Please avoid open-coding number.
> 
>> +
>> +vgic_unlock_irqs(pirqs, nrirqs);
>> +local_irq_restore(flags);
>> +
>> +return ret;
>> +}
>> +
>> +void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
>> + unsigned int first_irq, uint32_t value)
>> +{
>> +struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
>> +unsigned long flags;
>> +unsigned int i;
>> +
>> +local_irq_save(flags);
>> +vgic_lock_irqs(v, nrirqs, first_irq, pirqs);
>> +
>> +for ( i = 0; i < nrirqs; i++, value >>= 8 )
> 
> Same here.
> 
>> +pirqs[i]->priority = value & 0xff;
>> +
>> +vgic_unlock_irqs(pirqs, nrirqs);
>> +local_irq_restore(flags);
>> +}
>> +
>>  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned
>> int irq)
>>  {
>>  unsigned long flags;
>> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>> index ecf4969..f3791c8 100644
>> --- a/xen/include/asm-arm/vgic.h
>> +++ b/xen/include/asm-arm/vgic.h
>> @@ -198,6 +198,11 @@ void vgic_lock_irqs(struct vcpu *v, unsigned int
>> nrirqs, unsigned int first_irq,
>>  struct pending_irq **pirqs);
>>  void vgic_unlock_irqs(struct pending_irq **pirqs, unsigned int nrirqs);
>>
>> +uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,
>> + unsigned int first_irq);
>> +void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
>> + unsigned int first_irq, uint32_t reg);
>> +
>>  enum gic_sgi_mode;
>>
>>  /*
>>
> 
> Cheers,
> 

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

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

2017-08-16 Thread Julien Grall 



On 16/08/17 17:48, Andre Przywara wrote:

Hi,

On 11/08/17 15:10, Julien Grall wrote:

Hi Andre,

On 21/07/17 20:59, Andre Przywara wrote:

Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 37 +
 xen/include/asm-arm/vgic.h |  5 +
 2 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 434b7e2..b2c9632 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -243,6 +243,43 @@ static int vgic_get_virq_priority(struct vcpu *v,
unsigned int virq)
 return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
 }

+#define MAX_IRQS_PER_IPRIORITYR 4


The name gives the impression that you may have IPRIORITYR with only 1
IRQ. But this is not true. The registers is always 4. However, you are
able to access using byte or word.


+uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,


I am well aware that the vgic code is mixing between virq and irq.
Moving forward, we should use virq to avoid confusion.


+ unsigned int first_irq)


Please stay consistent, with the naming. Either nr_irqs/first_irq or
nrirqs/firstirq. But not a mix.


I totally agree, but check this out:
xen/include/asm-arm/irq.h:#define nr_irqs NR_IRQS

So wherever you write nr_irqs in *any* part of ARM IRQ code you end up
with a compile error ...
Not easy to fix, though, hence I moved to the name without the
underscore, even though I don't really like it.


Oh. On a side note, nr_irqs does not cover all the IRQs. It only covers 
up to SPIs. Which is a little bit odd.


Anyway, maybe you would rename it to nr. I think it is fairly straight 
forward that you deal with IRQ.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

2017-08-16 Thread Andre Przywara 
Hi,

On 11/08/17 15:10, Julien Grall wrote:
> Hi Andre,
> 
> On 21/07/17 20:59, Andre Przywara wrote:
>> Since the GICs MMIO access always covers a number of IRQs at once,
>> introduce wrapper functions which loop over those IRQs, take their
>> locks and read or update the priority values.
>> This will be used in a later patch.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/vgic.c| 37 +
>>  xen/include/asm-arm/vgic.h |  5 +
>>  2 files changed, 42 insertions(+)
>>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 434b7e2..b2c9632 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -243,6 +243,43 @@ static int vgic_get_virq_priority(struct vcpu *v,
>> unsigned int virq)
>>  return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
>>  }
>>
>> +#define MAX_IRQS_PER_IPRIORITYR 4
> 
> The name gives the impression that you may have IPRIORITYR with only 1
> IRQ. But this is not true. The registers is always 4. However, you are
> able to access using byte or word.
> 
>> +uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,
> 
> I am well aware that the vgic code is mixing between virq and irq.
> Moving forward, we should use virq to avoid confusion.
> 
>> + unsigned int first_irq)
> 
> Please stay consistent, with the naming. Either nr_irqs/first_irq or
> nrirqs/firstirq. But not a mix.

I totally agree, but check this out:
xen/include/asm-arm/irq.h:#define nr_irqs NR_IRQS

So wherever you write nr_irqs in *any* part of ARM IRQ code you end up
with a compile error ...
Not easy to fix, though, hence I moved to the name without the
underscore, even though I don't really like it.

Cheers,
Andre.

> 
> Also, it makes more sense to describe first the start then number.
> 
>> +{
>> +struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
>> +unsigned long flags;
>> +uint32_t ret = 0, i;
>> +
>> +local_irq_save(flags);
>> +vgic_lock_irqs(v, nrirqs, first_irq, pirqs);
> 
> I am not convinced on the usefulness of taking all the locks in one go.
> At one point in the time, you only need to lock a given pending_irq.
> 
>> +
>> +for ( i = 0; i < nrirqs; i++ )
>> +ret |= pirqs[i]->priority << (i * 8);
> 
> Please avoid open-coding number.
> 
>> +
>> +vgic_unlock_irqs(pirqs, nrirqs);
>> +local_irq_restore(flags);
>> +
>> +return ret;
>> +}
>> +
>> +void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
>> + unsigned int first_irq, uint32_t value)
>> +{
>> +struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
>> +unsigned long flags;
>> +unsigned int i;
>> +
>> +local_irq_save(flags);
>> +vgic_lock_irqs(v, nrirqs, first_irq, pirqs);
>> +
>> +for ( i = 0; i < nrirqs; i++, value >>= 8 )
> 
> Same here.
> 
>> +pirqs[i]->priority = value & 0xff;
>> +
>> +vgic_unlock_irqs(pirqs, nrirqs);
>> +local_irq_restore(flags);
>> +}
>> +
>>  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned
>> int irq)
>>  {
>>  unsigned long flags;
>> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>> index ecf4969..f3791c8 100644
>> --- a/xen/include/asm-arm/vgic.h
>> +++ b/xen/include/asm-arm/vgic.h
>> @@ -198,6 +198,11 @@ void vgic_lock_irqs(struct vcpu *v, unsigned int
>> nrirqs, unsigned int first_irq,
>>  struct pending_irq **pirqs);
>>  void vgic_unlock_irqs(struct pending_irq **pirqs, unsigned int nrirqs);
>>
>> +uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,
>> + unsigned int first_irq);
>> +void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
>> + unsigned int first_irq, uint32_t reg);
>> +
>>  enum gic_sgi_mode;
>>
>>  /*
>>
> 
> Cheers,
> 

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

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

2017-08-11 Thread Julien Grall 

Hi Andre,

On 21/07/17 20:59, Andre Przywara wrote:

Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 37 +
 xen/include/asm-arm/vgic.h |  5 +
 2 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 434b7e2..b2c9632 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -243,6 +243,43 @@ static int vgic_get_virq_priority(struct vcpu *v, unsigned 
int virq)
 return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
 }

+#define MAX_IRQS_PER_IPRIORITYR 4


The name gives the impression that you may have IPRIORITYR with only 1 
IRQ. But this is not true. The registers is always 4. However, you are 
able to access using byte or word.



+uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,


I am well aware that the vgic code is mixing between virq and irq. 
Moving forward, we should use virq to avoid confusion.



+ unsigned int first_irq)


Please stay consistent, with the naming. Either nr_irqs/first_irq or 
nrirqs/firstirq. But not a mix.


Also, it makes more sense to describe first the start then number.


+{
+struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
+unsigned long flags;
+uint32_t ret = 0, i;
+
+local_irq_save(flags);
+vgic_lock_irqs(v, nrirqs, first_irq, pirqs);


I am not convinced on the usefulness of taking all the locks in one go. 
At one point in the time, you only need to lock a given pending_irq.



+
+for ( i = 0; i < nrirqs; i++ )
+ret |= pirqs[i]->priority << (i * 8);


Please avoid open-coding number.


+
+vgic_unlock_irqs(pirqs, nrirqs);
+local_irq_restore(flags);
+
+return ret;
+}
+
+void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
+ unsigned int first_irq, uint32_t value)
+{
+struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
+unsigned long flags;
+unsigned int i;
+
+local_irq_save(flags);
+vgic_lock_irqs(v, nrirqs, first_irq, pirqs);
+
+for ( i = 0; i < nrirqs; i++, value >>= 8 )


Same here.


+pirqs[i]->priority = value & 0xff;
+
+vgic_unlock_irqs(pirqs, nrirqs);
+local_irq_restore(flags);
+}
+
 bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
 {
 unsigned long flags;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index ecf4969..f3791c8 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -198,6 +198,11 @@ void vgic_lock_irqs(struct vcpu *v, unsigned int nrirqs, 
unsigned int first_irq,
 struct pending_irq **pirqs);
 void vgic_unlock_irqs(struct pending_irq **pirqs, unsigned int nrirqs);

+uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,
+ unsigned int first_irq);
+void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
+ unsigned int first_irq, uint32_t reg);
+
 enum gic_sgi_mode;

 /*



Cheers,

--
Julien Grall

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

[Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

2017-07-21 Thread Andre Przywara 
Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 37 +
 xen/include/asm-arm/vgic.h |  5 +
 2 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 434b7e2..b2c9632 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -243,6 +243,43 @@ static int vgic_get_virq_priority(struct vcpu *v, unsigned 
int virq)
 return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
 }
 
+#define MAX_IRQS_PER_IPRIORITYR 4
+uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,
+ unsigned int first_irq)
+{
+struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
+unsigned long flags;
+uint32_t ret = 0, i;
+
+local_irq_save(flags);
+vgic_lock_irqs(v, nrirqs, first_irq, pirqs);
+
+for ( i = 0; i < nrirqs; i++ )
+ret |= pirqs[i]->priority << (i * 8);
+
+vgic_unlock_irqs(pirqs, nrirqs);
+local_irq_restore(flags);
+
+return ret;
+}
+
+void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
+ unsigned int first_irq, uint32_t value)
+{
+struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
+unsigned long flags;
+unsigned int i;
+
+local_irq_save(flags);
+vgic_lock_irqs(v, nrirqs, first_irq, pirqs);
+
+for ( i = 0; i < nrirqs; i++, value >>= 8 )
+pirqs[i]->priority = value & 0xff;
+
+vgic_unlock_irqs(pirqs, nrirqs);
+local_irq_restore(flags);
+}
+
 bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
 {
 unsigned long flags;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index ecf4969..f3791c8 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -198,6 +198,11 @@ void vgic_lock_irqs(struct vcpu *v, unsigned int nrirqs, 
unsigned int first_irq,
 struct pending_irq **pirqs);
 void vgic_unlock_irqs(struct pending_irq **pirqs, unsigned int nrirqs);
 
+uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,
+ unsigned int first_irq);
+void vgic_store_irq_priority(struct vcpu *v, unsigned int nrirqs,
+ unsigned int first_irq, uint32_t reg);
+
 enum gic_sgi_mode;
 
 /*
-- 
2.9.0


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