[PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved

[Auger Eric]

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 at redhat.com>

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.
>>