Re: [kvm-unit-tests PATCH v5 10/13] arm/arm64: ITS: INT functional tests

From: Marc Zyngier <maz@kernel.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>,
	eric.auger.pro@gmail.com, kvmarm@lists.cs.columbia.edu,
	kvm@vger.kernel.org, qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	drjones@redhat.com, andre.przywara@arm.com,
	peter.maydell@linaro.org, alexandru.elisei@arm.com,
	thuth@redhat.com
Subject: Re: [kvm-unit-tests PATCH v5 10/13] arm/arm64: ITS: INT functional tests
Date: Wed, 11 Mar 2020 14:00:16 +0000	[thread overview]
Message-ID: <301a8b402ff7e480e927b0f8f8b093f2@kernel.org> (raw)
In-Reply-To: <46f0ed1d-3bda-f91b-e2b0-addf1c61c373@redhat.com>

On 2020-03-11 13:48, Auger Eric wrote:
> Hi Zenghui,
> 
> On 3/11/20 12:59 PM, Zenghui Yu wrote:
>> Hi Eric,
>> 
>> On 2020/3/10 22:54, Eric Auger wrote:
>>> Triggers LPIs through the INT command.
>>> 
>>> the test checks the LPI hits the right CPU and triggers
>>> the right LPI intid, ie. the translation is correct.
>>> 
>>> Updates to the config table also are tested, along with inv
>>> and invall commands.
>>> 
>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>> 
>>> ---
>> 
>> [...]
>> 
>>> +static void test_its_trigger(void)
>>> +{
>>> +    struct its_collection *col3, *col2;
>>> +    struct its_device *dev2, *dev7;
>>> +
>>> +    if (its_prerequisites(4))
>>> +        return;
>>> +
>>> +    dev2 = its_create_device(2 /* dev id */, 8 /* nb_ites */);
>>> +    dev7 = its_create_device(7 /* dev id */, 8 /* nb_ites */);
>>> +
>>> +    col3 = its_create_collection(3 /* col id */, 3/* target PE */);
>>> +    col2 = its_create_collection(2 /* col id */, 2/* target PE */);
>>> +
>>> +    gicv3_lpi_set_config(8195, LPI_PROP_DEFAULT);
>>> +    gicv3_lpi_set_config(8196, LPI_PROP_DEFAULT);
>>> +
>>> +    its_send_invall(col2);
>>> +    its_send_invall(col3);
>> 
>> These two INVALLs should be issued after col2 and col3 are mapped,
>> otherwise this will cause the INVALL command error as per the spec
>> (though KVM doesn't complain it at all).
> Yes you're right. reading the spec again:
> 
> A command error occurs if any of the following apply:
> ../..
> The collection specified by ICID has not been mapped to an RDbase using
> MAPC.
> 
> But as mentionned in the cover letter, no real means to retrieve the
> error at the moment.

That is still a problem with the ITS. There is no architectural way
to report an error, even if the error numbers are architected...

One thing we could do though is to implement the stall model (as 
described
in 5.3.2). It still doesn't give us the error, but at least the command
queue would stop on detecting an error.

         M.
-- 
Jazz is not dead. It just smells funny...