On Tue, 3 Mar 2015, Ian Campbell wrote:
On Tue, 2015-03-03 at 12:00 +, Stefano Stabellini wrote:
+/* An edge triggered interrupt should now be pending. */
+t-ppi_state.pending = true;
+vcpu_unblock(t-v);
I was going to say that this is
On Tue, 2015-03-03 at 12:18 +, Ian Campbell wrote:
+/* Xen s/w state */
+unsigned long inprogress:1;
+};
Using a uint32_t bitmask would be more in line the rest of the code
style, but it is just a matter of taste.
You mean uint32_t inprogress:1 for
On Mon, 26 Jan 2015, Ian Campbell wrote:
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
To do this introduce the concept of routing a PPI to the currently
On Tue, 3 Mar 2015, Ian Campbell wrote:
On Tue, 2015-03-03 at 11:38 +, Stefano Stabellini wrote:
gic_set_irq_properties(desc, cpumask_of(smp_processor_id()),
GIC_PRI_IRQ);
-/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
- * route SPIs to
On Tue, 2015-03-03 at 11:38 +, Stefano Stabellini wrote:
gic_set_irq_properties(desc, cpumask_of(smp_processor_id()),
GIC_PRI_IRQ);
-/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
- * route SPIs to guests, it doesn't make any difference. */
-
On Mon, 2015-03-02 at 18:42 +, Stefano Stabellini wrote:
On Tue, 10 Feb 2015, Ian Campbell wrote:
Stefano,
do you have any comments on the viability of the general approach here
before I go off and start addressing the review comments?
I think that the general approach is OK
On Tue, 3 Mar 2015, Ian Campbell wrote:
On Mon, 2015-03-02 at 18:42 +, Stefano Stabellini wrote:
On Tue, 10 Feb 2015, Ian Campbell wrote:
Stefano,
do you have any comments on the viability of the general approach here
before I go off and start addressing the review comments?
On Tue, 2015-03-03 at 12:00 +, Stefano Stabellini wrote:
+/* An edge triggered interrupt should now be pending. */
+t-ppi_state.pending = true;
+vcpu_unblock(t-v);
I was going to say that this is trouble because
local_events_need_delivery
On Tue, 10 Feb 2015, Ian Campbell wrote:
Stefano,
do you have any comments on the viability of the general approach here
before I go off and start addressing the review comments?
I think that the general approach is OK
Cheers,
Ian.
On Mon, 2015-01-26 at 15:55 +, Ian Campbell
Stefano,
do you have any comments on the viability of the general approach here
before I go off and start addressing the review comments?
Cheers,
Ian.
On Mon, 2015-01-26 at 15:55 +, Ian Campbell wrote:
... instead of artificially masking the timer interrupt in the timer
state and relying
On 27/01/15 13:34, Ian Campbell wrote:
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..9074aca 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -156,6 +156,45 @@ static void gicv2_save_state(struct vcpu *v)
writel_gich(0, GICH_HCR);
}
Hi Ian,
On 26/01/15 15:55, Ian Campbell wrote:
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
To do this introduce the concept of routing a PPI to the
On Tue, 2015-01-27 at 13:16 +, Julien Grall wrote:
Hi Ian,
On 26/01/15 15:55, Ian Campbell wrote:
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
To do this introduce the concept of routing a PPI to the currently
running VCPU. For such interrupts irq_get_domain
14 matches
Mail list logo
