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

[Zenghui Yu]

Hi Eric,

On 2020/4/2 16:50, Auger Eric wrote:
> Hi Zenghui,
>
> On 3/30/20 12:43 PM, Zenghui Yu wrote:
> > Hi Eric,
> >
> > On 2020/3/20 17:24, 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 <address@hidden>
> >
> > [...]
> >
> > So I've tested this series and found that the "INT" test will sometimes
> > fail.
> >
> > "not ok 12 - gicv3: its-migration: dev2/eventid=20 triggers LPI 8195 en
> > PE #3 after migration
> > not ok 13 - gicv3: its-migration: dev7/eventid=255 triggers LPI 8196 on
> > PE #2 after migration"
> >
> >  From logs:
> > "INFO: gicv3: its-migration: Migration complete
> > INT dev_id=2 event_id=20
> > INFO: gicv3: its-migration: No LPI received whereas (cpuid=3,
> > intid=8195) was expected
> > FAIL: gicv3: its-migration: dev2/eventid=20 triggers LPI 8195 en PE #3
> > after migration
> > INT dev_id=7 event_id=255
> > INFO: gicv3: its-migration: No LPI received whereas (cpuid=2,
> > intid=8196) was expected
> > FAIL: gicv3: its-migration: dev7/eventid=255 triggers LPI 8196 on PE #2
> > after migration"
> >
> > > +static void check_lpi_stats(const char *msg)
> > > +{
> > > +    bool pass = false;
> > > +
> > > +    mdelay(100);
> >
> > After changing this to 'mdelay(1000)', the above error doesn't show up
> > anymore. But it sounds strange that 100ms is not enough to deliver a
> > single LPI. I haven't dig it further but will get back here later.
>
> Did you find some time to investigate this issue. Changing 100 to 1000
> has a huge impact on the overall test duration and I don't think it is
> sensible. Could you see what is your minimal value that pass the tests?

I can reproduce this issue with a very *low* probability so I failed
to investigate it :-(.  (It might because the LPI was delivered to a
busy vcpu...)

You can leave it as it is until someone else complain about it again.
Or take the similar approach as check_acked() - wait up to 5s for the
interrupt to be delivered, and bail out as soon as we see it.


Thanks,
Zenghui