Re: [xen-unstable-smoke test] 173492: regressions - FAIL

[Julien Grall <julien@xxxxxxx>]

(+ Bertrand & Stefano)

Hi Henry,

On 12/10/2022 07:39, Henry Wang wrote:
> > -----Original Message-----
> > Subject: Re: [xen-unstable-smoke test] 173492: regressions - FAIL
> >
> > On 11.10.2022 18:29, osstest service owner wrote:
> > > flight 173492 xen-unstable-smoke real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/173492/
> > >
> > > Regressions :-(
> > >
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >   test-arm64-arm64-xl-xsm      14 guest-start              fail REGR. vs. 173457
> > Parsing config from /etc/xen/debian.guest.osstest.cfg
> > libxl: debug: libxl_create.c:2079:do_domain_create: ao 0xaaaacaccf680:
> > create: how=(nil) callback=(nil) poller=0xaaaacaccefd0
> > libxl: detail: libxl_create.c:661:libxl__domain_make: passthrough: disabled
> > libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure
> > the domain
> > libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config:  - Allocate
> > 0 SPIs
> > libxl: error: libxl_create.c:709:libxl__domain_make: domain creation fail: No
> > such file or directory
So this is -ENOENT which could be returned by the P2M is it can't 
allocate a page table (see p2m_set_entry()).
> > libxl: error: libxl_create.c:1294:initiate_domain_create: cannot make domain:
> > -3
> >
> > Later flights don't fail here anymore, though.
> >
> > >   test-armhf-armhf-xl          14 guest-start              fail REGR. vs. 173457
> > Similar log contents here, but later flights continue to fail the same way.
> >
> > I'm afraid I can't draw conclusions from this; I haven't been able to spot
> > anything helpful in the hypervisor logs. My best guess right now is the use
> > of some uninitialized memory, which just happened to go fine in the later
> > flights for 64-bit.
It looks like the smoke flight failed on laxton0 but passed on 
rochester{0, 1}. The former is using GICv2 whilst the latter are using 
GICv3.
In the case of GICv2, we will create a P2M mapping when the domain is 
created. This is not necessary in the GICv3.
IIRC the P2M pool is only populated later on (we don't add a few pages 
like on x86). So I am guessing this is why we are seen failure.
If that's correct, then this is a complete oversight from me (I haven't 
done any GICv2 testing) while reviewing the series.
The easy way to solve it would be to add a few pages in the pool when 
the domain is created. I don't like it, but I think there other possible 
solutions would require more work as we would need to delay the mappings.
> I am also quite confused about this issue, as from my local test today on
> different Arm/Arm64 boards, this issue would be only triggered on some of
> them instead of all of them...
Did this include any GICv2 HW?

Cheers,

--
Julien Grall