Re: [Xen-devel] [xen-4.7-testing test] 137065: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.06.19 at 09:15,  wrote:
>>>> On 05.06.19 at 20:02, <ian.jackson@xxxxxxxxxx> wrote:
> > Jan Beulich writes ("Re: [Xen-devel] [xen-4.7-testing test] 137065: 
> > regressions 
> - 
> > FAIL"):
> >> The one you've picked looks to be a "fail never pass" one, so is perhaps
> >> not ideal. I've looked at a couple other ones, and in particular when the
> >> guests are supposedly 64-bit I notice two things
> >> - they look to be busy looping on vCPU 0,
> >> - the VMCS/VMCB dumps suggest they've never left early boot (i.e.
> >>   are still in 32-bit mode with paging still disabled), and may well still
> >>   be sitting inside the boot loader.
> >> I'm not at all certain though if this helps in any way.
> > 
> > I have not yet managed to make much progress with this.  In my most
> > recent attempt I backported all of the build fixes onto the
> > last-working Xen revision.
> > 
> > The branch I built and tested was this:
> >   iwj@xxxxxxxxxxxx-lab:xen.git/t.47
> 
> I would have wanted to look at what you've pulled in, but I couldn't
> figure how to transform this into a url usable from here.
> 
> > And it failed:
> >   flight 137255 xen-unstable play [play]
> >   http://logs.test-lab.xenproject.org/osstest/logs/137255/ 
> 
> And it's again is this early boot state, with vCPU 0 spinning on
> something. As I'm only now noticing, this
> 
> (XEN) RSP = 0x00000000005c2d48 (0x00000000005c2d48)  RIP = 
> 0x00000000001015db (0x00000000001015db)
> 
> might actually hint at it being in hvmloader. The guest state dump
> would match up with this:
> 
> (XEN) RIP:    0018:[<00000000001015e0>]
> 
> Both would point into hvmloader()'s memset. In this latter case we
> also have the remaining registers, which are interesting:
> 
> (XEN) rax: 00000000005c2d50   rbx: 000000000010da9c   rcx: 00000000000002ff
> (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
> (XEN) rbp: 00000000005c2d58   rsp: 00000000005c2d48   r8:  0000000000000000
> 
> rax is the address that was just written to (or on the first iteration
> is the address about to be written to). It's pretty odd that rax
> points exactly between rsp and rbp, i.e. at local variable space of
> memset() itself. No caller should ever call the function like this.
> 
> Seeing these addresses and seeing
> 
> (d1) Testing HVM environment:
> 
> as the last line of guest output I wonder whether you need to pull
> in 0d6968635c ("hvmloader: avoid tests when they would clobber
> used memory"). If nevertheless executing the tests is desired,
> e2fc5bb5cb ("hvmloader: dynamically determine scratch memory
> range for tests") would also be needed (but then also on 4.8 and
> 4.9).

FTR - I've applied the first of these to the 4.7 branch (should have
done so before the weekend, to avoid wasting yet another flight).
If it helps (as I expect), then it may also want go onto the 4.6 one.
Otoh we could as well decide to retire 4.7 (the 3 years from its
initial release expire on Thursday according to my records), at
which point the need to fiddle with the 4.6 branch (for use as
"prev" in 4.7 testing) as well as the need to actually spend testing
resources on it would vanish. But perhaps it's better to have 4.7
get a final "full" push ...

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel