Hi Ian,
On 20/02/2015 17:41, Julien Grall wrote:
+/* Only SPIs are supported */
+if ( virq 32 || virq = vgic_num_irqs(d) )
+return -EINVAL;
+
+p = irq_to_pending(d-vcpu[0], virq);
+if ( !p-desc )
+return -EINVAL;
Are we seeing this pattern a lot? It seems
On Fri, 2015-02-20 at 17:41 +, Julien Grall wrote:
+/* TODO: Handle eviction from LRs. For now, deny remove if the IRQ
+ * is inflight and not disabled.
If we are ungracefully killing a guest doesn't this risk ending up with
an undestroyable domain? i.e. if the guest is
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e has
Furthermore (I think your finger macros have this one wrong, you might
want to grep the series ;-))
+/* TODO: Handle eviction from LRs. For now, deny remove
Hi Ian,
On 20/02/15 16:31, Ian Campbell wrote:
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e has
Furthermore (I think your finger macros have this one wrong, you might
want to grep the series ;-))
I do this
On Tue, 13 Jan 2015, Julien Grall wrote:
Xen has to release IRQ routed to a domain in order to reuse later. Currently
only SPIs can be routed to the guest so we only need to browse SPIs for a
specific domain.
Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e has
not
Xen has to release IRQ routed to a domain in order to reuse later. Currently
only SPIs can be routed to the guest so we only need to browse SPIs for a
specific domain.
Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e has
not being EOIed). Xen will have to reset the IRQ in
