All of lore.kernel.org
 help / color / mirror / Atom feed
* [xen-unstable-smoke test] 92827: regressions - FAIL
@ 2016-04-26 13:01 osstest service owner
  2016-04-26 13:13 ` Wei Liu
  0 siblings, 1 reply; 7+ messages in thread
From: osstest service owner @ 2016-04-26 13:01 UTC (permalink / raw)
  To: xen-devel, osstest-admin

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  722b6d259f408b80c40e3ddb6b5909414be31f57
baseline version:
 xen                  488c2a860a6d7eb69f4acfeb349b457aaba76dfa

Last test of basis    92731  2016-04-25 17:04:22 Z    0 days
Testing same since    92827  2016-04-26 10:06:00 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Wei Liu <wei.liu2@citrix.com>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     fail    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 722b6d259f408b80c40e3ddb6b5909414be31f57
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Apr 26 11:54:08 2016 +0200

    Revert "HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."
    
    This reverts commit 2716d875379d538c1dfccad78a99ca7db2e09f90.
    
    As it was decided that the existing XENVER hypercall - while having
    grown organically over the years can still be expanded.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Requested-and-acked-by: Jan Beulich <jbeulich@suse.com>

commit f3598690741671a933eb372877bcb59f7036b1df
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Apr 26 11:53:49 2016 +0200

    Revert "libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall"
    
    This reverts commit d275ec9ca8a86f7c9c213f3551194d471ce90fbd.
    
    As we prefer to still utilize the old XENVER_ hypercall.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>

commit 0129e1ee0d61fc93f6101332719d0bb5de6718ad
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 26 11:53:18 2016 +0200

    x86/xstate: don't clobber or leak state when using XSAVES
    
    Commit 4d27280572 ("x86/xsaves: fix overwriting between non-lazy/lazy
    xsaves") switched to always saving full state when using compacted
    format (which is the only one XSAVES allows). It didn't, however, also
    adjust the restore side: In order to save full state, we also need to
    make sure we always load full state, or else the subject vCPU's state
    would get clobbered by that of the vCPU which happened to last have in
    use the respective component(s).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Release-acked-by: Wei Liu <wei.liu2@citrix.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit 3a6222bd57209d4c2f098d61ace042370a9b0a96
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 26 11:52:22 2016 +0200

    x86/vMSI-X: avoid missing first unmask of vectors
    
    Recent changes to Linux result in there just being a single unmask
    operation prior to expecting the first interrupts to arrive. However,
    we've had a chicken-and-egg problem here: Qemu invokes
    xc_domain_update_msi_irq(), ultimately leading to
    msixtbl_pt_register(), upon seeing that first unmask operation. Yet
    for msixtbl_range() to return true (in order to msixtbl_write() to get
    invoked at all) msixtbl_pt_register() must have completed.
    
    Deal with this by snooping suitable writes in msixtbl_range() and
    triggering the invocation of msix_write_completion() from
    msixtbl_pt_register() when that happens in the context of a still in
    progress vector control field write.
    
    Note that the seemingly unrelated deletion of the redundant
    irq_desc->msi_desc check in msixtbl_pt_register() is to make clear to
    any compiler version used that the "msi_desc" local variable isn't
    being used uninitialized. (Doing the same in msixtbl_pt_unregister() is
    just for consistency reasons.)
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
    Release-acked-by: Wei Liu <wei.liu2@citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [xen-unstable-smoke test] 92827: regressions - FAIL
  2016-04-26 13:01 [xen-unstable-smoke test] 92827: regressions - FAIL osstest service owner
@ 2016-04-26 13:13 ` Wei Liu
  2016-04-26 13:45   ` Jan Beulich
  2016-04-26 13:54   ` Paul Durrant
  0 siblings, 2 replies; 7+ messages in thread
From: Wei Liu @ 2016-04-26 13:13 UTC (permalink / raw)
  To: osstest service owner
  Cc: Andrew Cooper, xen-devel, Wei Liu, Jan Beulich, Paul Durrant

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
Apr 26 10:56:02.583638 (XEN)    [<ffff82d0801cd3a1>] hvm.c#__hvm_copy+0x130/0x3c0
Apr 26 10:56:02.591618 (XEN)    [<ffff82d0801cf050>] hvm_copy_from_guest_virt_nofault+0x14/0x16
Apr 26 10:56:02.599646 (XEN)    [<ffff82d0801cf48d>] copy_from_user_hvm+0x6d/0x8d
Apr 26 10:56:02.599683 (XEN)    [<ffff82d08018a5f0>] compat_arch_memory_op+0x103/0x549
Apr 26 10:56:02.607618 (XEN)    [<ffff82d08013d7db>] compat_memory_op+0xb2b/0x1282
Apr 26 10:56:02.615607 (XEN)    [<ffff82d0801cbbfa>] hvm.c#hvm_memory_op_compat32+0x42/0x50
Apr 26 10:56:02.615646 (XEN)    [<ffff82d0801d1c1d>] hvm_do_hypercall+0x392/0x624
Apr 26 10:56:02.623592 (XEN)    [<ffff82d0801f71b2>] vmx_vmexit_handler+0xe17/0x1a10
Apr 26 10:56:02.631611 (XEN)    [<ffff82d0801fc821>] vmx_asm_vmexit_handler+0x41/0x120
Apr 26 10:56:02.631648 (XEN) 
Apr 26 10:56:02.639550 (XEN) 
Apr 26 10:56:02.639576 (XEN) ****************************************
Apr 26 10:56:02.639606 (XEN) Panic on CPU 3:
Apr 26 10:56:02.639632 (XEN) Assertion 'r->type == IOREQ_TYPE_COPY' failed at vmsi.c:352
Apr 26 10:56:02.647475 (XEN) ****************************************
Apr 26 10:56:02.655441 (XEN) 
Apr 26 10:56:02.655456 (XEN) Reboot in five seconds...
Apr 26 10:56:02.655471 (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [xen-unstable-smoke test] 92827: regressions - FAIL
  2016-04-26 13:13 ` Wei Liu
@ 2016-04-26 13:45   ` Jan Beulich
  2016-04-26 13:54   ` Paul Durrant
  1 sibling, 0 replies; 7+ messages in thread
From: Jan Beulich @ 2016-04-26 13:45 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, Paul Durrant, osstest service owner, xen-devel

>>> On 26.04.16 at 15:13, <wei.liu2@citrix.com> wrote:
> CC Jan, Paul and Andrew

I'll look into this.

Jan

> 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-d 
> ebianhvm-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
> Apr 26 10:56:02.583638 (XEN)    [<ffff82d0801cd3a1>] 
> hvm.c#__hvm_copy+0x130/0x3c0
> Apr 26 10:56:02.591618 (XEN)    [<ffff82d0801cf050>] 
> hvm_copy_from_guest_virt_nofault+0x14/0x16
> Apr 26 10:56:02.599646 (XEN)    [<ffff82d0801cf48d>] 
> copy_from_user_hvm+0x6d/0x8d
> Apr 26 10:56:02.599683 (XEN)    [<ffff82d08018a5f0>] 
> compat_arch_memory_op+0x103/0x549
> Apr 26 10:56:02.607618 (XEN)    [<ffff82d08013d7db>] 
> compat_memory_op+0xb2b/0x1282
> Apr 26 10:56:02.615607 (XEN)    [<ffff82d0801cbbfa>] 
> hvm.c#hvm_memory_op_compat32+0x42/0x50
> Apr 26 10:56:02.615646 (XEN)    [<ffff82d0801d1c1d>] 
> hvm_do_hypercall+0x392/0x624
> Apr 26 10:56:02.623592 (XEN)    [<ffff82d0801f71b2>] 
> vmx_vmexit_handler+0xe17/0x1a10
> Apr 26 10:56:02.631611 (XEN)    [<ffff82d0801fc821>] 
> vmx_asm_vmexit_handler+0x41/0x120
> Apr 26 10:56:02.631648 (XEN) 
> Apr 26 10:56:02.639550 (XEN) 
> Apr 26 10:56:02.639576 (XEN) ****************************************
> Apr 26 10:56:02.639606 (XEN) Panic on CPU 3:
> Apr 26 10:56:02.639632 (XEN) Assertion 'r->type == IOREQ_TYPE_COPY' failed at 
> vmsi.c:352
> Apr 26 10:56:02.647475 (XEN) ****************************************
> Apr 26 10:56:02.655441 (XEN) 
> Apr 26 10:56:02.655456 (XEN) Reboot in five seconds...
> Apr 26 10:56:02.655471 (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [xen-unstable-smoke test] 92827: regressions - FAIL
  2016-04-26 13:13 ` Wei Liu
  2016-04-26 13:45   ` Jan Beulich
@ 2016-04-26 13:54   ` Paul Durrant
  2016-04-26 14:12     ` Jan Beulich
  1 sibling, 1 reply; 7+ messages in thread
From: Paul Durrant @ 2016-04-26 13:54 UTC (permalink / raw)
  To: osstest service owner, Jan Beulich; +Cc: Andrew Cooper, xen-devel, Wei Liu

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 26 April 2016 14:14
> To: osstest service owner
> Cc: xen-devel@lists.xensource.com; 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....

Jan,

  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.

  Paul

> Apr 26 10:56:02.583638 (XEN)    [<ffff82d0801cd3a1>]
> hvm.c#__hvm_copy+0x130/0x3c0
> Apr 26 10:56:02.591618 (XEN)    [<ffff82d0801cf050>]
> hvm_copy_from_guest_virt_nofault+0x14/0x16
> Apr 26 10:56:02.599646 (XEN)    [<ffff82d0801cf48d>]
> copy_from_user_hvm+0x6d/0x8d
> Apr 26 10:56:02.599683 (XEN)    [<ffff82d08018a5f0>]
> compat_arch_memory_op+0x103/0x549
> Apr 26 10:56:02.607618 (XEN)    [<ffff82d08013d7db>]
> compat_memory_op+0xb2b/0x1282
> Apr 26 10:56:02.615607 (XEN)    [<ffff82d0801cbbfa>]
> hvm.c#hvm_memory_op_compat32+0x42/0x50
> Apr 26 10:56:02.615646 (XEN)    [<ffff82d0801d1c1d>]
> hvm_do_hypercall+0x392/0x624
> Apr 26 10:56:02.623592 (XEN)    [<ffff82d0801f71b2>]
> vmx_vmexit_handler+0xe17/0x1a10
> Apr 26 10:56:02.631611 (XEN)    [<ffff82d0801fc821>]
> vmx_asm_vmexit_handler+0x41/0x120
> Apr 26 10:56:02.631648 (XEN)
> Apr 26 10:56:02.639550 (XEN)
> Apr 26 10:56:02.639576 (XEN)
> ****************************************
> Apr 26 10:56:02.639606 (XEN) Panic on CPU 3:
> Apr 26 10:56:02.639632 (XEN) Assertion 'r->type == IOREQ_TYPE_COPY' failed
> at vmsi.c:352
> Apr 26 10:56:02.647475 (XEN)
> ****************************************
> Apr 26 10:56:02.655441 (XEN)
> Apr 26 10:56:02.655456 (XEN) Reboot in five seconds...
> Apr 26 10:56:02.655471 (XEN) Resetting with ACPI MEMORY or I/O
> RESET_REG.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [xen-unstable-smoke test] 92827: regressions - FAIL
  2016-04-26 13:54   ` Paul Durrant
@ 2016-04-26 14:12     ` Jan Beulich
  2016-04-26 14:37       ` Paul Durrant
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2016-04-26 14:12 UTC (permalink / raw)
  To: Paul Durrant; +Cc: Andrew Cooper, Wei Liu, osstest service owner, xen-devel

>>> On 26.04.16 at 15:54, <Paul.Durrant@citrix.com> wrote:
>>  -----Original Message-----
>> From: Wei Liu [mailto:wei.liu2@citrix.com]
>> Sent: 26 April 2016 14:14
>> To: osstest service owner
>> Cc: xen-devel@lists.xensource.com; 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@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [xen-unstable-smoke test] 92827: regressions - FAIL
  2016-04-26 14:12     ` Jan Beulich
@ 2016-04-26 14:37       ` Paul Durrant
  2016-04-26 14:57         ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Durrant @ 2016-04-26 14:37 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, osstest service owner, xen-devel

> -----Original Message-----
[snip]
> >> 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.

IIRC it's an optimization to avoid p2m lookups (or other overhead) that would be pointless when the address is MMIO. Perhaps this could be avoided in another way e.g. by having certain emulators add their address ranges to a list and checking against that instead?

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

True. I guess a small workaround is to check the vcpu ioreq state and make sure it's not 'none' before checking the type. In the case where hvm_mmio_internal is called there should be no emulation in progress so I think that would work.

  Paul

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [xen-unstable-smoke test] 92827: regressions - FAIL
  2016-04-26 14:37       ` Paul Durrant
@ 2016-04-26 14:57         ` Jan Beulich
  0 siblings, 0 replies; 7+ messages in thread
From: Jan Beulich @ 2016-04-26 14:57 UTC (permalink / raw)
  To: Paul Durrant; +Cc: Andrew Cooper, Wei Liu, osstest service owner, xen-devel

>>> On 26.04.16 at 16:37, <Paul.Durrant@citrix.com> wrote:
>>  -----Original Message-----
> [snip]
>> >> 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.
> 
> IIRC it's an optimization to avoid p2m lookups (or other overhead) that 
> would be pointless when the address is MMIO.

It's an optimization, yes, but one that is quite important for keeping
certain (iirc) Windows versions running even with reasonably high
vCPU counts.

> Perhaps this could be avoided in 
> another way e.g. by having certain emulators add their address ranges to a 
> list and checking against that instead?

That would be an option, but would duplicate state being tracked.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-04-26 14:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-26 13:01 [xen-unstable-smoke test] 92827: regressions - FAIL osstest service owner
2016-04-26 13:13 ` Wei Liu
2016-04-26 13:45   ` Jan Beulich
2016-04-26 13:54   ` Paul Durrant
2016-04-26 14:12     ` Jan Beulich
2016-04-26 14:37       ` Paul Durrant
2016-04-26 14:57         ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.