[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 internally). --- 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) ) - { vlapic_EOI_set(vlapic); - isr = vlapic_find_highest_isr(vlapic); - } + + isr = vlapic_find_highest_isr(vlapic); /* * The specification says that if APIC assist is set and a -- 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |