[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable-smoke test] 92827: regressions - FAIL
>>> On 26.04.16 at 15:54, <Paul.Durrant@xxxxxxxxxx> wrote: >> -----Original Message----- >> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx] >> Sent: 26 April 2016 14:14 >> To: osstest service owner >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Wei Liu; Jan Beulich; Paul Durrant; >> Andrew Cooper >> Subject: Re: [Xen-devel] [xen-unstable-smoke test] 92827: regressions - FAIL >> >> CC Jan, Paul and Andrew >> >> On Tue, Apr 26, 2016 at 01:01:32PM +0000, osstest service owner wrote: >> > flight 92827 xen-unstable-smoke real [real] >> > http://logs.test-lab.xenproject.org/osstest/logs/92827/ >> > >> > Regressions :-( >> > >> > Tests which did not succeed and are blocking, >> > including tests which could not be run: >> > test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail >> REGR. vs. 92731 >> >> http://logs.test-lab.xenproject.org/osstest/logs/92827/test-amd64-amd64- >> xl-qemuu-debianhvm-i386/serial-fiano1.log >> >> Apr 26 10:56:02.287445 (d1) HVM Loader >> Apr 26 10:56:02.327467 (d1) Detected Xen v4.7-unstable >> Apr 26 10:56:02.335490 (XEN) Assertion 'r->type == IOREQ_TYPE_COPY' failed >> at vmsi.c:352 >> Apr 26 10:56:02.335531 (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Not >> tainted ]---- >> Apr 26 10:56:02.343504 (XEN) CPU: 3 >> Apr 26 10:56:02.343534 (XEN) RIP: e008:[<ffff82d0801e2d3c>] >> vmsi.c#msixtbl_range+0x6e/0xab >> Apr 26 10:56:02.351504 (XEN) RFLAGS: 0000000000010297 CONTEXT: >> hypervisor (d1v0) >> Apr 26 10:56:02.359499 (XEN) rax: 000000000000000c rbx: ffff82d08033c0a8 >> rcx: ffff83026bd0e608 >> Apr 26 10:56:02.367502 (XEN) rdx: 0000000000000000 rsi: 00000000003bfa0c >> rdi: 0000000000000000 >> Apr 26 10:56:02.367543 (XEN) rbp: ffff830277eb7ae8 rsp: ffff830277eb7ac8 >> r8: 0000000000000001 >> Apr 26 10:56:02.375474 (XEN) r9: 00000000deadf00d r10: ffff82d0802eebc0 >> r11: 0000000000000000 >> Apr 26 10:56:02.383492 (XEN) r12: 00000000003bfa0c r13: ffff83007dce3000 >> r14: ffff830277eb0000 >> Apr 26 10:56:02.391501 (XEN) r15: ffff83007dce3000 cr0: 000000008005003b >> cr4: 00000000001526e0 >> Apr 26 10:56:02.399556 (XEN) cr3: 000000026bc92000 cr2: 0000000000000000 >> Apr 26 10:56:02.399591 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: > 0000 >> cs: e008 >> Apr 26 10:56:02.407619 (XEN) Xen code around <ffff82d0801e2d3c> >> (vmsi.c#msixtbl_range+0x6e/0xab): >> Apr 26 10:56:02.415619 (XEN) 00 bd 9f 09 00 00 01 74 <02> 0b 41 0f b6 85 9e > 09 >> 00 00 ba 00 00 00 00 a8 >> Apr 26 10:56:02.423608 (XEN) Xen stack trace from rsp=ffff830277eb7ac8: >> Apr 26 10:56:02.423644 (XEN) ffff830277eb7b58 ffff830259140170 >> 00000000003bfa0c ffff830277eb7b58 >> Apr 26 10:56:02.431612 (XEN) ffff830277eb7b18 ffff82d0801d65ce >> ffff830277eb7b18 ffff830259140170 >> Apr 26 10:56:02.439615 (XEN) 000000000000000b ffff83026bd0e000 >> ffff830277eb7b48 ffff82d0801d696e >> Apr 26 10:56:02.447640 (XEN) 00000000003bfa0c 00000000003bfa0c >> ffff820080000000 0000000000000008 >> Apr 26 10:56:02.455587 (XEN) ffff830277eb7b78 ffff82d0801d6b2c >> 00000000003bfa0c 0000000000000000 >> Apr 26 10:56:02.463604 (XEN) 0000000100000001 0100000000000000 >> ffff830277eb7c28 ffff82d0801cd3a1 >> Apr 26 10:56:02.463643 (XEN) ffff830277eb7b98 ffff83007dce3000 >> ffff830277eb7bf4 ffff830277eb0000 >> Apr 26 10:56:02.471610 (XEN) ffff830277eb7be4 ffff82d0801306d1 >> ffff830277eb7c08 0000000400000004 >> Apr 26 10:56:02.479606 (XEN) ffff830277eb7c84 0000000000000a0c >> 00000000000003bf 0000000100000008 >> Apr 26 10:56:02.487633 (XEN) ffff82d08027ae11 ffff83026bd0eaa4 >> 0000000000000000 0000000000000008 >> Apr 26 10:56:02.495606 (XEN) 0000000000000009 ffff820080000000 >> ffff830277eb7f18 ffff820080000000 >> Apr 26 10:56:02.503633 (XEN) ffff830277eb7c38 ffff82d0801cf050 >> ffff830277eb7c58 ffff82d0801cf48d >> Apr 26 10:56:02.503674 (XEN) 0000000000000080 00000000003bfa0c >> ffff830277eb7ce8 ffff82d08018a5f0 >> Apr 26 10:56:02.511615 (XEN) 0000000000000001 0000000000000000 >> ffff83026bd0e000 0000000077eb7e0a >> Apr 26 10:56:02.519618 (XEN) ffff830277eb7cb8 ffff82d0801cb478 >> ffff830277eb7d48 ffff830277eb7d68 >> Apr 26 10:56:02.527606 (XEN) 0000000000000000 ffff830259140190 >> ffff830277eb7cd8 ffff830277eb7f18 >> Apr 26 10:56:02.535607 (XEN) ffff83007dce3000 0000000000000000 >> ffff830277eb7f18 ffff820080000000 >> Apr 26 10:56:02.543607 (XEN) ffff830277eb7dc8 ffff82d08013d7db >> ffff830277eb7d68 ffff830277eb7e0a >> Apr 26 10:56:02.551600 (XEN) ffff830277eb7d38 ffff830259140190 >> ffff830277eb7d68 ffff830277eb7d90 >> Apr 26 10:56:02.551638 (XEN) ffff830277eb7d60 ffff830277eb7d68 >> ffff830277eb0000 ffff82d0801d69b9 >> Apr 26 10:56:02.559620 (XEN) Xen call trace: >> Apr 26 10:56:02.559651 (XEN) [<ffff82d0801e2d3c>] >> vmsi.c#msixtbl_range+0x6e/0xab >> Apr 26 10:56:02.567604 (XEN) [<ffff82d0801d65ce>] >> intercept.c#hvm_mmio_accept+0x6a/0xe4 >> Apr 26 10:56:02.575611 (XEN) [<ffff82d0801d696e>] >> hvm_find_io_handler+0x65/0x89 >> Apr 26 10:56:02.583602 (XEN) [<ffff82d0801d6b2c>] >> hvm_mmio_internal+0x37/0x61 > > Ah. Crap. I forgot about this path.... So did I. And my testing didn't catch it because I have a post-4.7 patch in place avoiding registration of the vMSI-X handler when there are no passed through devices, and on the box where I do use pass-through I normally run with debug=n. > I think the best way round this is to have vmsi register as an full io > interceptor so its accept method can use the passed in ioreq, which is faked > up to be a copy in this case. Either that or get rid of hvm_mmio_internal() > altogether. Getting rid of it is not possible afaict. And converting to a full I/O interceptor is a bad idea not just because of the backporting issue, but also because we really don't _want_ to snoop accesses coming through hvm_mmio_internal(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |