[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()
Hello Julien, Sorry for the previous email sent as html. On 27.10.18 15:14, Andrii Anisov wrote: >>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c >>> index f6f6de3..985192b 100644 >>> --- a/xen/arch/arm/traps.c >>> +++ b/xen/arch/arm/traps.c >>> @@ -2095,6 +2095,7 @@ static void enter_hypervisor_head(struct >>> cpu_user_regs *regs) >>> if ( current->arch.hcr_el2 & HCR_VA ) >>> current->arch.hcr_el2 = READ_SYSREG(HCR_EL2); >>> >>> + gic_store_lrs(); >> >> gic_clear_lrs(...) may rewrite the LRs. To confirm this stall LRs are >> not due by this function, can you move that after gic_clear_lrs()? > Right you are, gic_clear_lrs(), in 4.10 codebase, rewrites LRs. But it > does not change PENDING to INVALID under no circumstances from one > hand. From another hand, all changes to LRs are made through gic > specific operations gic_hw_ops->... which are tracked by me. You can > see, in the code above, that I copy all updates to the physical LR > issued by hypervisor into the stored LRs. So it not the case. But I'll > check on Monday. In 4.12-unstable code base I moved gic_store_lrs() after vgic_sync_from_lrs() and see significant changes. Now stale lines are printed at very high rate, and it is the proper behavior. Because the correspondent check (performed when vgic_sync_from_lrs() reads LRs) detects that VM processes interrupts and LR values are changed comparing to those set by hypervisor lately. So now it is the question, why could I detect spurious changes in LRs without exiting to VM? -- *Andrii Anisov* _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |