[PATCH] xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop.

[PATCH] xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop.

[Konrad Rzeszutek Wilk]

From: Keir Fraser <keir.fraser@citrix.com>

This avoids any other hardirq handler seeing a very stale jiffies
value immediately after wakeup from a long idle period. The one
observable symptom of this was a USB keyboard, with software keyboard
repeat, which would always repeat a key immediately that it was
pressed. This is due to the key press waking the guest, the key
handler immediately runs, sees an old jiffies value, and then that
jiffies value significantly updated, before the key is unpressed.

Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index aa85881..2647ad8 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1316,7 +1316,7 @@ static void __xen_evtchn_do_upcall(void)
 {
 	int start_word_idx, start_bit_idx;
 	int word_idx, bit_idx;
-	int i;
+	int i, irq;
 	int cpu = get_cpu();
 	struct shared_info *s = HYPERVISOR_shared_info;
 	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
@@ -1324,6 +1324,8 @@ static void __xen_evtchn_do_upcall(void)
 
 	do {
 		xen_ulong_t pending_words;
+		xen_ulong_t pending_bits;
+		struct irq_desc *desc;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
@@ -1335,6 +1337,17 @@ static void __xen_evtchn_do_upcall(void)
 		 * selector flag. xchg_xen_ulong must contain an
 		 * appropriate barrier.
 		 */
+		if ((irq = per_cpu(virq_to_irq, cpu)[VIRQ_TIMER]) != -1) {
+			int evtchn = evtchn_from_irq(irq);
+			word_idx = evtchn / BITS_PER_LONG;
+			pending_bits = evtchn % BITS_PER_LONG;
+			if (active_evtchns(cpu, s, word_idx) & (1ULL << pending_bits)) {
+				desc = irq_to_desc(irq);
+				if (desc)
+					generic_handle_irq_desc(irq, desc);
+			}
+		}
+
 		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
@@ -1343,7 +1356,6 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			xen_ulong_t pending_bits;
 			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
@@ -1372,8 +1384,7 @@ static void __xen_evtchn_do_upcall(void)
 
 			do {
 				xen_ulong_t bits;
-				int port, irq;
-				struct irq_desc *desc;
+				int port;
 
 				bits = MASK_LSBS(pending_bits, bit_idx);
 
-- 
1.8.0.2

Re: [Xen-devel] [PATCH] xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop.

[David Vrabel]

On 01/04/13 15:07, Konrad Rzeszutek Wilk wrote:
> From: Keir Fraser <keir.fraser@citrix.com>
> 
> This avoids any other hardirq handler seeing a very stale jiffies
> value immediately after wakeup from a long idle period. The one
> observable symptom of this was a USB keyboard, with software keyboard
> repeat, which would always repeat a key immediately that it was
> pressed. This is due to the key press waking the guest, the key
> handler immediately runs, sees an old jiffies value, and then that
> jiffies value significantly updated, before the key is unpressed.

It's a bit of hack but what else can you do when there is no generic
mechanism to have different event priorities.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

The subject should be prefixed with: "xen/events" as this isn't a patch
to the evtchn driver.

David

Re: [Xen-devel] [PATCH] xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop.

[David Vrabel]

On 01/04/13 15:07, Konrad Rzeszutek Wilk wrote:
> From: Keir Fraser <keir.fraser@citrix.com>
> 
> This avoids any other hardirq handler seeing a very stale jiffies
> value immediately after wakeup from a long idle period. The one
> observable symptom of this was a USB keyboard, with software keyboard
> repeat, which would always repeat a key immediately that it was
> pressed. This is due to the key press waking the guest, the key
> handler immediately runs, sees an old jiffies value, and then that
> jiffies value significantly updated, before the key is unpressed.

It's a bit of hack but what else can you do when there is no generic
mechanism to have different event priorities.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

The subject should be prefixed with: "xen/events" as this isn't a patch
to the evtchn driver.

David