From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: [PATCH v5 12/22] xen/arm: ITS: Add GICR register
 emulation
Date: Mon, 3 Aug 2015 14:58:42 +0100
Message-ID: <55BF7392.2090803@citrix.com>
References: <1437995524-19772-1-git-send-email-vijay.kilari@gmail.com>
	<1437995524-19772-13-git-send-email-vijay.kilari@gmail.com>
	<55BA591C.6020004@citrix.com>
	<CALicx6txSfsMe+imhWHDszTqZw-2MZ1mSqGGChEKMoH7uZbBUA@mail.gmail.com>
	<55BB5678.2040108@citrix.com>
	<CALicx6uJaySKZ7xZYjmYzo_q9rx-YusGVmaxzn97iHfTaAmn7g@mail.gmail.com>
	<55BCEB05.5010002@citrix.com>
	<CALicx6t-qMk0pCbd63R5aYjiah+PZjZ+9oxXyWrSzbGF0XCxLg@mail.gmail.com>
	<55BF6612.9030303@citrix.com>
	<CALicx6tHpZnDW2_nLct9B6Egs6yHvD2x+YLc1Nrgy=MZcZ1mwQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CALicx6tHpZnDW2_nLct9B6Egs6yHvD2x+YLc1Nrgy=MZcZ1mwQ@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Vijay Kilari <vijay.kilari@gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>, manish.jaggi@caviumnetworks.com, Tim Deegan <tim@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
List-Id: xen-devel@lists.xenproject.org

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?

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