[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



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