[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [XEN PATCH v3 07/11] xen: arm: vgic: allow delivery of PPIs to guests



Hi,

On 26/11/2019 01:20, Stefano Stabellini wrote:
On Mon, 25 Nov 2019, Julien Grall wrote:
(+ Andre)

On 23/11/2019 20:35, Julien Grall wrote:
Hi,

On 15/11/2019 20:10, Stewart Hildebrand wrote:
Allow vgic_get_hw_irq_desc to be called with a vcpu argument.

Use vcpu argument in vgic_connect_hw_irq.

vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce with
ASSERTs.

Signed-off-by: Stewart Hildebrand <stewart.hildebrand@xxxxxxxxxxxxxxx>

---
v3: new patch

---
Note: I have only modified the old vgic to allow delivery of PPIs.

The new vGIC should also be modified to support delivery of PPIs.

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 82f524a35c..c3933c2687 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -410,10 +410,10 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r,
int n)
               irq_set_affinity(p->desc, cpumask_of(v_target->processor));
               spin_lock_irqsave(&p->desc->lock, flags);
               /*
-             * The irq cannot be a PPI, we only support delivery of SPIs
-             * to guests.
+             * The irq cannot be a SGI, we only support delivery of SPIs
+             * and PPIs to guests.
                */
-            ASSERT(irq >= 32);
+            ASSERT(irq >= NR_SGIS);

We usually put ASSERT() in place we know that code wouldn't be able to work
correctly if there ASSERT were hit. In this particular case:

               if ( irq_type_set_by_domain(d) )
                   gic_set_irq_type(p->desc, vgic_get_virq_type(v, n, i));

1) We don't want to allow any domain (including Dom0) to modify the
interrupt type (i.e. level/edge) for PPIs as this is shared. You will also
most likely need to modify the counterpart in setup_guest_irq().

               p->desc->handler->enable(p->desc);

2) On GICv3, the re-distributor of vCPU A is accessible by vCPU B. So vCPU B
could enable the SGI for vCPU A. But this would be called on the wrong pCPU
leading to inconsistency between the hardware state of the internal vGIC
state.

Is it actually meant to work from a GIC specification perspective? It
sounds "wrong" somehow to me, but I went through the spec and it doesn't
say explicitly that cpuB couldn't enable a SGI/PPI of cpuA. I am still
a bit shocked by this revelation.

To be honest, I can see reason to allow this but this is a different subject.

In this case the re-distributor is per-CPU and can accessible by any CPU. For instance, Linux will access it to find the re-distributor associated to a given CPU at boot.

FWIW, the vGIC implementation in KVM handles it the same way.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.