Hi Zenghui,
On 3/13/20 3:06 AM, Zenghui Yu wrote:
> On 2020/3/11 21:51, Eric Auger wrote:
>> +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);
>> +
>> + report_prefix_push("int");
>> + /*
>> + * dev=2, eventid=20 -> lpi= 8195, col=3
>> + * dev=7, eventid=255 -> lpi= 8196, col=2
>> + * Trigger dev2, eventid=20 and dev7, eventid=255
>> + * Check both LPIs hit
>> + */
>> +
>> + its_send_mapd(dev2, true);
>> + its_send_mapd(dev7, true);
>> +
>> + its_send_mapc(col3, true);
>> + its_send_mapc(col2, true);
>> +
>> + its_send_invall(col2);
>> + its_send_invall(col3);
>> +
>> + its_send_mapti(dev2, 8195 /* lpi id */, 20 /* event id */, col3);
>> + its_send_mapti(dev7, 8196 /* lpi id */, 255 /* event id */, col2);
>> +
>> + lpi_stats_expect(3, 8195);
>> + its_send_int(dev2, 20);
>> + check_lpi_stats("dev=2, eventid=20 -> lpi= 8195, col=3");
>> +
>> + lpi_stats_expect(2, 8196);
>> + its_send_int(dev7, 255);
>> + check_lpi_stats("dev=7, eventid=255 -> lpi= 8196, col=2");
>> +
>> + report_prefix_pop();
>> +
>> + report_prefix_push("inv/invall");
>> +
>> + /*
>> + * disable 8195, check dev2/eventid=20 does not trigger the
>> + * corresponding LPI
>> + */
>> + gicv3_lpi_set_config(8195, LPI_PROP_DEFAULT & ~LPI_PROP_ENABLED);
>> + its_send_inv(dev2, 20);
>> +
>> + lpi_stats_expect(-1, -1);
>> + its_send_int(dev2, 20);
>> + check_lpi_stats("dev2/eventid=20 does not trigger any LPI");
>> +
>> + /*
>> + * re-enable the LPI but willingly do not call invall
>> + * so the change in config is not taken into account.
>> + * The LPI should not hit
>> + */
>> + gicv3_lpi_set_config(8195, LPI_PROP_DEFAULT);
>> + lpi_stats_expect(-1, -1);
>> + its_send_int(dev2, 20);
>> + check_lpi_stats("dev2/eventid=20 still does not trigger any LPI");
>> +
>> + /* Now call the invall and check the LPI hits */
>> + its_send_invall(col3);
>> + lpi_stats_expect(3, 8195);
>> + its_send_int(dev2, 20);
>> + check_lpi_stats("dev2/eventid=20 now triggers an LPI");
>> +
>> + report_prefix_pop();
>> +
>> + report_prefix_push("mapd valid=false");
>> + /*
>> + * Unmap device 2 and check the eventid 20 formerly
>> + * attached to it does not hit anymore
>> + */
>> +
>> + its_send_mapd(dev2, false);
>> + lpi_stats_expect(-1, -1);
>> + its_send_int(dev2, 20);
>
> Here. You issued an INT command while the dev2 has just been unmapped,
> this will be detected by ITS as a command error. We may end-up failed
> to see the completion of this command (under the ITS stall mode).
I agree this is a case where it is expected to fail. However at the
moment we don't have stall kernel support and the way I test it fails is
by issuing the below
lpi_stats_expect(-1, -1);
check_lpi_stats("no LPI after device unmap");
Otherwise I cannot test this scenario.
I suggest once we get the stall support in kernel, we revisit the tests.
Thanks
Eric
>
>
> Thanks,
> Zenghui
>
>> + check_lpi_stats("no LPI after device unmap");
>> + report_prefix_pop();
>> +}
>
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
