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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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).

Jan



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