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

[Andrew Jones]

On Thu, Apr 02, 2020 at 08:40:42PM +0800, Zenghui Yu wrote:
> 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.

I think the check_acked approach would be the best approach.

Thanks,
drew

> 
> 
> Thanks,
> Zenghui
> 
>