Re: [Xen-devel] [PATCH v5 12/22] xen/arm: ITS: Add GICR register emulation

[Vijay Kilari <vijay.kilari@xxxxxxxxx>]

On Mon, Aug 3, 2015 at 7:28 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> On 03/08/15 14:51, Vijay Kilari wrote:
>>> If so, this is wrong for 2 reasons:
>>>         1) The guest may decide to setup a bigger property table later.
>>>         2) vgic.id_bits should never be touched. The GITS_TYPER is static 
>>> and
>>> defined before the guest is booted.
>>
>>  If GICR_PROPBASER.id_bits is always subset of GITS_TYPER then
>> we should always limit size of LPI property table to id_bits or
>> vgic.id_bits whichever
>> is smaller.
>>
>> While injecting LPI drop which is beyond LPI property table or LPI
>> property table is not
>> set.
>
> I don't understand what you mean here.
>
>>>>>
>>>>> What would happen if the LPI is injected before the GICR_PROPBASER is
>>>>> enabled? See for more details on the problem here [1]
>>>>
>>>>  Check is required before accessing LPI property table if property
>>>> table is available
>>>> or not?.
>>>
>>> You didn't answer to my question... What would you do if the property is
>>> not available? Ignoring the LPI? Would the LPI can fire back after the
>>> property table is set and the LPI enabled?
>>
>>    Same as above solution.  Ignore LPI as we don't have LPI property
>> information to inject.
>
> That still not answering to my question. What happen if we ignore the
> LPI? Would the device resend the MSI and therefore the LPI later? If
> not, how do you plan to handle this?
>
  LPIs are edge triggered, so device won't raise again.

We can put in inflight and wait for guest to enabled it, But we are not sure
when LPI property table will be set for this vLPI. On GICR_PROPBASER update
with new property table, we parse the LPI property table and call
vits_{enable/disable}_lpi

> With the LPI implementation, it's valid to receive an LPI before the
> guest effectively setup the ITS (i.e property table and the mapping to a
> vLPI). This is because we enable to LPI as soon as we route it to the guest.
>
> Regards,
>
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel