* [xen-unstable test] 105966: regressions - FAIL
@ 2017-02-22 18:20 osstest service owner
2017-02-23 9:51 ` Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: osstest service owner @ 2017-02-22 18:20 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 105966 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 105933
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 105933
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105933
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 105933
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 105933
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105933
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 105933
test-amd64-amd64-xl-rtds 9 debian-install fail like 105933
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 105933
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a
test-arm64-arm64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a
test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a
test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-xsm 5 xen-build fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
build-arm64 5 xen-build fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
build-arm64-pvops 5 kernel-build fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-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
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
version targeted for testing:
xen b908131167a67a16fbe9c7a7826b67e2d93d9ec5
baseline version:
xen 2f5af2c962c05b789bdd65b46c74711e903f86d0
Last test of basis 105933 2017-02-20 20:13:35 Z 1 days
Failing since 105946 2017-02-21 10:19:53 Z 1 days 2 attempts
Testing same since 105966 2017-02-21 23:23:44 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap <george.dunlap@citrix.com>
Kevin Tian <kevin.tian@intel.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm fail
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 fail
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt blocked
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops fail
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl blocked
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm blocked
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm blocked
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 blocked
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-arm64-arm64-libvirt blocked
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-arm64-arm64-xl-multivcpu blocked
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-arm64-arm64-libvirt-qcow2 blocked
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-arm64-arm64-xl-rtds blocked
test-armhf-armhf-xl-rtds pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 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 b908131167a67a16fbe9c7a7826b67e2d93d9ec5
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Nov 2 15:50:23 2016 +0000
x86/emul: Support CPUID faulting via a speculative MSR read
This removes the need for every cpuid() emulation hook to individually support
CPUID faulting.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 65ddae6e3ce54373860cf53c589e6eafaba5eba5
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Nov 2 15:50:23 2016 +0000
x86/emul: Introduce common msr_val for emulation
Use it consistently in place of local tsc_aux, msr_content and val
declarations, and replace opencoded uses of X86EMUL_OKAY.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 49de10f3c1718bb952f4b075d07f37eb9f605b2b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Nov 2 14:36:49 2016 +0000
x86/hvm: Don't raise #GP behind the emulators back for MSR accesses
The current hvm_msr_{read,write}_intercept() infrastructure calls
hvm_inject_hw_exception() directly to latch a fault, and returns
X86EMUL_EXCEPTION to its caller.
This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
fault is raised behind the back of the x86 emulator.
Alter the behaviour so hvm_msr_{read,write}_intercept() simply returns
X86EMUL_EXCEPTION, leaving the callers to actually inject the #GP fault.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
commit 38b48605f3693e950bb4155ea8dac6614d796c2b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sun Dec 18 14:56:28 2016 +0000
x86/vmx: Drop vmx_msr_state infrastructure
To avoid leaking host MSR state into guests, guest LSTAR, STAR and
SYSCALL_MASK state is unconditionally loaded when switching into guest
context.
Attempting to dirty-track the state is pointless; host state is always
restoring upon exit from guest context, meaning that guest state is always
considered dirty.
Drop struct vmx_msr_state, enum VMX_INDEX_MSR_* and msr_index[]. The guests
MSR values are stored plainly in arch_vmx_struct, in the same way as shadow_gs
and cstar are. vmx_restore_guest_msrs() and long_mode_do_msr_write() ensure
that the hardware MSR values are always up-to-date.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 394e66b0d04f0281b9c6231dad1377c4b9fea7d0
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sun Dec 18 14:56:28 2016 +0000
x86/vmx: Remove vmx_save_host_msrs() and host_msr_state
A pcpu's LSTAR, STAR and SYSCALL_MASK MSRs are unconditionally switched when
moving in and out of HVM vcpu context. Two of these values are compile time
constants, and the third is directly available in an existing per-cpu
variable.
There is no need to save host state in vmx_cpu_up() into a different per-cpu
structure, so drop all the infrastructure. vmx_restore_host_msrs() is
simplified to 3 plain WRMSR instructions.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 36b35babdf381b8e2843d37e29da2ddc01ec3282
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sun Dec 18 14:56:28 2016 +0000
x86/setup: Intoduce XEN_MSR_STAR
Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
new define and use it to avoid the opencoding in subarch_percpu_traps_init()
and restore_rest_processor_state().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 2f1add6e1c8789d979daaafa3d80ddc1bc375783
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sun Dec 18 14:20:49 2016 +0000
x86/vmx: Don't leak host syscall MSR state into HVM guests
hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
restored when switching into guest context. It should never have been part of
the migration state to start with, and Xen must not make any decisions based
on the value seen during restore.
Identify it as obsolete in the header files, consistently save it as zero and
ignore it on restore.
The MSRs must be considered dirty during VMCS creation to cause the proper
defaults of 0 to be visible to the guest.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
commit 5dbd60e16a1f29b9f1f84088c5cab1be2dac7a7a
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon Jul 4 09:40:34 2016 +0100
x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
lower than the real maxphysaddr, to avoid overflowing the superpage shadow
backpointer.
However, plenty of hardware has a physical address width less that 44 bits,
and the code added in shadow_domain_init() is a straight assignment. This
causes gfn_bits to be increased beyond the physical address width on most
Intel consumer hardware (typically a width of 39, which is the number reported
to the guest via CPUID).
If the guest intentionally creates a PTE referencing a physical address
between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
address. However, the shadow code accepts the PTE, shadows it, and the
virtual address works normally.
Introduce paging_max_paddr_bits() to calculate the largest guest physical
address supportable by the paging infrastructure, and update
recalculate_cpuid_policy() to take this into account when clamping the guests
cpuid_policy to reality.
There is an existing gfn_valid() in guest_pt.h but it is unused in the
codebase. Repurpose it to perform a guest-specific maxphysaddr check, which
replaces the users of gfn_bits.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 105966: regressions - FAIL
2017-02-22 18:20 [xen-unstable test] 105966: regressions - FAIL osstest service owner
@ 2017-02-23 9:51 ` Jan Beulich
2017-02-23 12:19 ` Andrew Cooper
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2017-02-23 9:51 UTC (permalink / raw)
To: Andrew Cooper, xen-devel; +Cc: osstest-admin
>>> On 22.02.17 at 19:20, <osstest-admin@xenproject.org> wrote:
> flight 105966 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105966/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 105933
(XEN) d5v0: Invalid EFER update: 0x1d01 -> 0x3901 - LMSLE without support
(XEN) hvm.c:1616:d3v0 All CPUs offline -- powering off.
Very interesting. Earlier instances of the first of these two messages
in the log indicate that this previously didn't cause the guest to die. I
can't guess which of the commits under test might be responsible,
though, so unless someone else has any idea we may need to wait
for the bisector to give us a clue. The most likely one would seem to
be 49de10f3c1 ("x86/hvm: Don't raise #GP behind the emulators
back for MSR accesses") - Andrew, is the much later #GP injection
(in hvm_do_resume()) perhaps the problem here? Shouldn't this
be done in svm_do_msr_access() and VMX's EXIT_REASON_MSR_WRITE
handling, respectively?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 105966: regressions - FAIL
2017-02-23 9:51 ` Jan Beulich
@ 2017-02-23 12:19 ` Andrew Cooper
2017-02-23 12:24 ` Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cooper @ 2017-02-23 12:19 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: osstest-admin
On 23/02/17 09:51, Jan Beulich wrote:
>>>> On 22.02.17 at 19:20, <osstest-admin@xenproject.org> wrote:
>> flight 105966 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/105966/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 105933
> (XEN) d5v0: Invalid EFER update: 0x1d01 -> 0x3901 - LMSLE without support
> (XEN) hvm.c:1616:d3v0 All CPUs offline -- powering off.
>
> Very interesting. Earlier instances of the first of these two messages
> in the log indicate that this previously didn't cause the guest to die.
Looks like a red herring. It is d5 complaining about EFER, while d3
that dies mysteriously.
> I can't guess which of the commits under test might be responsible,
> though, so unless someone else has any idea we may need to wait
> for the bisector to give us a clue. The most likely one would seem to
> be 49de10f3c1 ("x86/hvm: Don't raise #GP behind the emulators
> back for MSR accesses") - Andrew, is the much later #GP injection
> (in hvm_do_resume()) perhaps the problem here? Shouldn't this
> be done in svm_do_msr_access() and VMX's EXIT_REASON_MSR_WRITE
> handling, respectively?
I don't think so. Normal MSR accesses would be via svm_do_msr_access()
which still latches #GP on the way out.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 105966: regressions - FAIL
2017-02-23 12:19 ` Andrew Cooper
@ 2017-02-23 12:24 ` Jan Beulich
2017-02-23 12:38 ` Andrew Cooper
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2017-02-23 12:24 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, osstest-admin
>>> On 23.02.17 at 13:19, <andrew.cooper3@citrix.com> wrote:
> On 23/02/17 09:51, Jan Beulich wrote:
>>>>> On 22.02.17 at 19:20, <osstest-admin@xenproject.org> wrote:
>>> flight 105966 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/105966/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>> test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 105933
>> (XEN) d5v0: Invalid EFER update: 0x1d01 -> 0x3901 - LMSLE without support
>> (XEN) hvm.c:1616:d3v0 All CPUs offline -- powering off.
>>
>> Very interesting. Earlier instances of the first of these two messages
>> in the log indicate that this previously didn't cause the guest to die.
>
> Looks like a red herring. It is d5 complaining about EFER, while d3
> that dies mysteriously.
Oops, I didn't pay enough attention.
>> I can't guess which of the commits under test might be responsible,
>> though, so unless someone else has any idea we may need to wait
>> for the bisector to give us a clue. The most likely one would seem to
>> be 49de10f3c1 ("x86/hvm: Don't raise #GP behind the emulators
>> back for MSR accesses") - Andrew, is the much later #GP injection
>> (in hvm_do_resume()) perhaps the problem here? Shouldn't this
>> be done in svm_do_msr_access() and VMX's EXIT_REASON_MSR_WRITE
>> handling, respectively?
>
> I don't think so. Normal MSR accesses would be via svm_do_msr_access()
> which still latches #GP on the way out.
But anyway - is the exception injection in hvm_do_resume() really
legitimate?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 105966: regressions - FAIL
2017-02-23 12:24 ` Jan Beulich
@ 2017-02-23 12:38 ` Andrew Cooper
2017-02-23 12:51 ` Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cooper @ 2017-02-23 12:38 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, osstest-admin
On 23/02/17 12:24, Jan Beulich wrote:
>>>> On 23.02.17 at 13:19, <andrew.cooper3@citrix.com> wrote:
>> On 23/02/17 09:51, Jan Beulich wrote:
>>>>>> On 22.02.17 at 19:20, <osstest-admin@xenproject.org> wrote:
>>>> flight 105966 xen-unstable real [real]
>>>> http://logs.test-lab.xenproject.org/osstest/logs/105966/
>>>>
>>>> Regressions :-(
>>>>
>>>> Tests which did not succeed and are blocking,
>>>> including tests which could not be run:
>>>> test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 105933
>>> (XEN) d5v0: Invalid EFER update: 0x1d01 -> 0x3901 - LMSLE without support
>>> (XEN) hvm.c:1616:d3v0 All CPUs offline -- powering off.
>>>
>>> Very interesting. Earlier instances of the first of these two messages
>>> in the log indicate that this previously didn't cause the guest to die.
>> Looks like a red herring. It is d5 complaining about EFER, while d3
>> that dies mysteriously.
> Oops, I didn't pay enough attention.
Should we reorder the prink() to put %pv before __FILE__ ? IMO it would
be helpful to have %pv in a more consistent location in the line.
>
>>> I can't guess which of the commits under test might be responsible,
>>> though, so unless someone else has any idea we may need to wait
>>> for the bisector to give us a clue. The most likely one would seem to
>>> be 49de10f3c1 ("x86/hvm: Don't raise #GP behind the emulators
>>> back for MSR accesses") - Andrew, is the much later #GP injection
>>> (in hvm_do_resume()) perhaps the problem here? Shouldn't this
>>> be done in svm_do_msr_access() and VMX's EXIT_REASON_MSR_WRITE
>>> handling, respectively?
>> I don't think so. Normal MSR accesses would be via svm_do_msr_access()
>> which still latches #GP on the way out.
> But anyway - is the exception injection in hvm_do_resume() really
> legitimate?
I have brought that up before. It is not actually legitimate, because
%rip has already moved forwards by this point.
In practice, the current vmevent users of this interface only intercept
a very small number of MSRs, and they won't fault by the time they get here.
ISTR suggesting that this bit of vm_event moves to an X86EMUL_RETRY
model. However, that will break other areas of the vm_event
infrastructure iirc, so is rather complicated to do.
I was hoping all of these problems could be deferred until I started
looking into the action-emulator plan, to bring together the various
paths we currently have putting the same action into the vm_event ring.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 105966: regressions - FAIL
2017-02-23 12:38 ` Andrew Cooper
@ 2017-02-23 12:51 ` Jan Beulich
0 siblings, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2017-02-23 12:51 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, osstest-admin
>>> On 23.02.17 at 13:38, <andrew.cooper3@citrix.com> wrote:
> On 23/02/17 12:24, Jan Beulich wrote:
>>>>> On 23.02.17 at 13:19, <andrew.cooper3@citrix.com> wrote:
>>> On 23/02/17 09:51, Jan Beulich wrote:
>>>>>>> On 22.02.17 at 19:20, <osstest-admin@xenproject.org> wrote:
>>>>> flight 105966 xen-unstable real [real]
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/105966/
>>>>>
>>>>> Regressions :-(
>>>>>
>>>>> Tests which did not succeed and are blocking,
>>>>> including tests which could not be run:
>>>>> test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 105933
>>>> (XEN) d5v0: Invalid EFER update: 0x1d01 -> 0x3901 - LMSLE without support
>>>> (XEN) hvm.c:1616:d3v0 All CPUs offline -- powering off.
>>>>
>>>> Very interesting. Earlier instances of the first of these two messages
>>>> in the log indicate that this previously didn't cause the guest to die.
>>> Looks like a red herring. It is d5 complaining about EFER, while d3
>>> that dies mysteriously.
>> Oops, I didn't pay enough attention.
>
> Should we reorder the prink() to put %pv before __FILE__ ? IMO it would
> be helpful to have %pv in a more consistent location in the line.
That's a good idea, I think.
>>>> I can't guess which of the commits under test might be responsible,
>>>> though, so unless someone else has any idea we may need to wait
>>>> for the bisector to give us a clue. The most likely one would seem to
>>>> be 49de10f3c1 ("x86/hvm: Don't raise #GP behind the emulators
>>>> back for MSR accesses") - Andrew, is the much later #GP injection
>>>> (in hvm_do_resume()) perhaps the problem here? Shouldn't this
>>>> be done in svm_do_msr_access() and VMX's EXIT_REASON_MSR_WRITE
>>>> handling, respectively?
>>> I don't think so. Normal MSR accesses would be via svm_do_msr_access()
>>> which still latches #GP on the way out.
>> But anyway - is the exception injection in hvm_do_resume() really
>> legitimate?
>
> I have brought that up before. It is not actually legitimate, because
> %rip has already moved forwards by this point.
>
> In practice, the current vmevent users of this interface only intercept
> a very small number of MSRs, and they won't fault by the time they get here.
Well, this means effectively you added dead code. Yet in that case
I think it would be better for the dead code to crash the domain,
instead of trying to inject an event after vendor specific resume
code has already run. That would at least make obvious that we
don't expect this path to be taken.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-23 12:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-22 18:20 [xen-unstable test] 105966: regressions - FAIL osstest service owner
2017-02-23 9:51 ` Jan Beulich
2017-02-23 12:19 ` Andrew Cooper
2017-02-23 12:24 ` Jan Beulich
2017-02-23 12:38 ` Andrew Cooper
2017-02-23 12:51 ` 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.