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

[Xen-devel] [PATCH] x86/hvm: remove duplicate vlapic_find_highest_isr() calls

When viridian APIC assist is active, the code in vlapic_has_pending_irq()
may end up re-calling vlapic_find_highest_isr() after emulating an EOI
whereas simply moving the call after the EOI emulation removes the need
for this duplication.

Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
Cc: Jan Beulich <jbeulich@xxxxxxxx>
Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
Cc: "Roger Pau Monné" <roger.pau@xxxxxxxxxx>

I'm not sure why the code ended up this way. Both calls were added by
commit 66bf4ef0486 "x86/hvm: re-work viridian APIC assist code" but there
seems to be no good reason for the duplication. I can only think that an
interim development version of the code fed the initially sampled ISR into
an open-coded version of vlapic_EOI_set() (which makes the call
 xen/arch/x86/hvm/vlapic.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index bdf946b25a..4f02499b3b 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1246,18 +1246,15 @@ int vlapic_has_pending_irq(struct vcpu *v)
          !nestedhvm_vcpu_in_guestmode(v) )
         return irr;
-    isr = vlapic_find_highest_isr(vlapic);
      * If APIC assist was set then an EOI may have been avoided.
      * If so, we need to emulate the EOI here before comparing ISR
      * with IRR.
     if ( viridian_apic_assist_completed(v) )
-    {
-        isr = vlapic_find_highest_isr(vlapic);
-    }
+    isr = vlapic_find_highest_isr(vlapic);
      * The specification says that if APIC assist is set and a

Xen-devel mailing list



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