Hi, On 07/11/2017 23:24, Auger Eric wrote: > Hi > > On 07/11/2017 17:34, Marc Zyngier wrote: >> On 07/11/17 16:12, Auger Eric wrote: >>> Hi Marc, >>> >>> On 07/11/2017 16:38, Marc Zyngier wrote: >>>> On 07/11/17 15:24, Auger Eric wrote: >>>>> Hi Marc, >>>>> >>>>> Hi Marc, >>>>> On 27/10/2017 16:28, Marc Zyngier wrote: >>>>>> The GICv4 architecture doesn't make it easy for save/restore to >>>>>> work, as it doesn't give any guarantee that the pending state >>>>>> is written into the pending table. >>>>> >>>>> I don't understand where does the limitation exactly come from. Can't we >>>>> use the GICR_VPENDBASER table data? >>>> You can't. None of the tables that are written by either the ITS or the >>>> redistributors are architected. All you know is that there is one bit >>>> per vLPI, but that's it (you don't even know which one is which). >>> Oh I thought the redistributor config and pending tables were fully >>> specified (6.1.2 and 6.1.3 of the spec), except the 1kB of the pending >>> table. >> >> The property table is definitely architected. It is a lot less clear for >> the pending table. The main issue is that you cannot really know when >> the various bits have actually been flushed all the way from the >> redistributor caches to memory to be introspected. Yes, it sucks. > Oh OK the INV only guarantees the caches are consistent with the LPI > config table. Maybe you could clarify the commit message with those details. > > So > Reviewed-by: Eric Auger <eric.auger@xxxxxxxxxx> Reading the spec further, looks setting the Valid bit of GICR_VPENDBASER is supposed to force the redistributor to retrieve pending interrupts from the the VCPU I/F and ensure the VPT in memory is correct. Anyway that's not a big deal at the moment as you pointed out... Thanks Eric > > Thanks > > Eric > >> >> Thanks, >> >> M. >>
