* [xen-unstable test] 25689: regressions - FAIL
@ 2014-03-31 20:25 xen.org
2014-03-31 20:45 ` Boris Ostrovsky
0 siblings, 1 reply; 6+ messages in thread
From: xen.org @ 2014-03-31 20:25 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 25689 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/25689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail REGR. vs. 25685
test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail REGR. vs. 25685
test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate.2 fail REGR. vs. 25685
test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 25685
test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 10 migrate-support-check fail never pass
test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass
version targeted for testing:
xen b021348231e942a342fd82e7a60193256236274d
baseline version:
xen 9011c2615c18b92f10cda8d78622e0c2a9e1f846
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemut-rhel6hvm-amd fail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-i386-freebsd10-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-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv blocked
test-amd64-i386-pv blocked
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-i386-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xl-qemuu-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-amd64-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit b021348231e942a342fd82e7a60193256236274d
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri Mar 28 13:48:39 2014 +0100
public/platform.h: replace unsigned long with xen_ulong_t
Replace unsigned long with xen_ulong_t in public/platform.h.
Also replace unsigned int with uint32_t for clarity. It is safe because
unsigned int are 4 byte sized and 4 byte aligned an all the supported
architectures.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
commit 226bc8ee4e0fd26bd3cbdb533eb447fdcd7a90bf
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:44:44 2014 +0100
x86/vMTRR: pass domain to mtrr_*_msr_set()
This is in preparation for the next patch, and mtrr_def_type_msr_set()
and mtrr_fix_range_msr_set() in sync with mtrr_var_range_msr_set() in
this regard.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit 1f8b57779785bf9f55c16312bb1ec679929c314b
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:43:25 2014 +0100
x86/EPT: relax treatment of APIC MFN
There's no point in this being mapped UC by the guest due to using a
respective PAT index - set the ignore-PAT flag to true.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit 90e9c95f9713f413d6e7b2e19492d4e038a319b9
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:42:43 2014 +0100
x86/EPT: also dump permissions and memory types
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit 3d8d2bd048773ababfa65cc8781b9ab3f5cf0eb0
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:37:10 2014 +0100
x86/EPT: simplification and cleanup
- drop rsvd*_ prefixes from fields not really reserved anymore
- replace odd uses of <expr> ? 1 : 0
- drop pointless variables from ept_set_entry()
- streamline IOMMU mirroring code in ept_set_entry()
- don't open code is_epte_valid() (and properly use it when dumping)
- streamline entry cloning in ept_split_super_page()
- compact dumping code and output
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit e5ae6eefdfbc1816b050d02998f69f0b78d5c814
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:36:19 2014 +0100
x86/p2m: make p2m_change_type() behavior match p2m_change_entry_type_global()'s
- don't reset access permissions
- don't shatter super pages
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit ef437690af8b75e6758dce77af75a22b63982883
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:33:34 2014 +0100
x86/HVM: correct CPUID leaf 80000008 handling
CPUID[80000008].EAX[23:16] have been given the meaning of the guest
physical address restriction (in case it needs to be smaller than the
host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
Enforce a lower limit at the same time, as well as a fixed value for
the virtual address bits, and zero for the guest physical address ones.
In order for the vMTRR code to see these overrides we need to make it
call hvm_cpuid() instead of domain_cpuid(), which in turn requires
special casing (and relaxing) the controlling domain.
This additionally should hide an ordering problem in the tools: Both
xend and xl appear to be restoring a guest from its image before
setting up the CPUID policy in the hypervisor, resulting in
domain_cpuid() returning all zeros and hence the check in
mtrr_var_range_msr_set() failing if the guest previously had more than
the minimum 36 physical address bits.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit 8bad6c5626129ffba04dbab3a38115b6f3669596
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:31:23 2014 +0100
x86/HVM: fix preemption handling in do_hvm_op()
Just like previously done for some mem-op hypercalls, undo preemption
using the interface structures (altering it in ways the caller may not
expect) and replace it by storing the continuation point in the high
bits of sub-operation argument.
This also changes the "nr" fields of struct xen_hvm_track_dirty_vram
(operation already limited to 1Gb worth of pages) and struct
xen_hvm_modified_memory to be only 32 bits wide, consistent with those
of struct xen_set_mem{type,access}. If that's not acceptable for some
reason, we'd need to shrink the HVMOP_op_bits (while still enforcing
the [then higher] limit resulting from the need to be able to encode
the continuation).
Whether (and if so how) to adjust xc_hvm_track_dirty_vram(),
xc_hvm_modified_memory(), xc_hvm_set_mem_type(), and
xc_hvm_set_mem_access() to reflect the 32-bit restriction on "nr" is
unclear: If the APIs need to remain stable, all four functions should
probably check that there was no truncation. Preferably their
parameters would be changed to uint32_t or unsigned int, though.
As a minor cleanup, along with introducing the switch-wide "pfn" the
redundant "d" is also being converted to a switch-wide one.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit 8d134c2e12730a4a3dce9873f4671f6dd8860baf
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 28 13:30:10 2014 +0100
x86/HVM: simplify do_hvm_op()
- boundary checks in HVMOP_modified_memory, HVMOP_set_mem_type, and
HVMOP_set_mem_access: all of these already check for overflow, so
there's no need to range check the first _and_ last PFN (checking
the last one suffices)
- copying back interface structures that were previously copied from
guest memory can use __copy_to_...(), since copy_from_...() already
did the address range validation
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
(qemu changes not included)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 25689: regressions - FAIL
2014-03-31 20:25 [xen-unstable test] 25689: regressions - FAIL xen.org
@ 2014-03-31 20:45 ` Boris Ostrovsky
2014-04-01 8:38 ` Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Boris Ostrovsky @ 2014-03-31 20:45 UTC (permalink / raw)
To: xen.org; +Cc: xen-devel, David Vrabel, Jan Beulich
On 03/31/2014 04:25 PM, xen.org wrote:
> flight 25689 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/25689/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail REGR. vs. 25685
> test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail REGR. vs. 25685
> test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate.2 fail REGR. vs. 25685
> test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 25685
> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
> test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
> test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
I was just about to report a regression that may be what these failures
also are.
Looks like 8bad6c562 (x86/HVM: fix preemption handling in do_hvm_op() )
broke qemu-traditional with HVM guests. Quite a few of
(XEN) hvm.c:2762:d25v0 guest attempted write to read-only memory page.
gfn=0x102, mfn=0x239086
followed by
(XEN) hvm.c:1475:d24v0 Triple fault on VCPU0 - invoking HVM shutdown
action 1.
-boris
>
> Tests which did not succeed, but are not blocking:
> test-armhf-armhf-xl 10 migrate-support-check fail never pass
> test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
> test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a
> test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
> test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
> test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass
> test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
> test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass
> test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass
> test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass
> test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass
> test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass
> test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass
>
> version targeted for testing:
> xen b021348231e942a342fd82e7a60193256236274d
> baseline version:
> xen 9011c2615c18b92f10cda8d78622e0c2a9e1f846
>
> ------------------------------------------------------------
> People who touched revisions under test:
> Ian Campbell <ian.campbell@citrix.com>
> Jan Beulich <jbeulich@suse.com>
> Keir Fraser <keir@xen.org>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ------------------------------------------------------------
>
> jobs:
> build-amd64 pass
> build-armhf pass
> build-i386 pass
> build-amd64-oldkern pass
> build-i386-oldkern pass
> build-amd64-pvops pass
> build-armhf-pvops pass
> build-i386-pvops pass
> test-amd64-amd64-xl pass
> test-armhf-armhf-xl pass
> test-amd64-i386-xl pass
> test-amd64-i386-rhel6hvm-amd pass
> test-amd64-i386-qemut-rhel6hvm-amd fail
> test-amd64-i386-qemuu-rhel6hvm-amd pass
> test-amd64-i386-freebsd10-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-amd64-amd64-xl-win7-amd64 fail
> test-amd64-i386-xl-win7-amd64 fail
> test-amd64-i386-xl-credit2 pass
> test-amd64-i386-freebsd10-i386 pass
> test-amd64-amd64-xl-pcipt-intel fail
> test-amd64-i386-rhel6hvm-intel pass
> test-amd64-i386-qemut-rhel6hvm-intel fail
> test-amd64-i386-qemuu-rhel6hvm-intel pass
> test-amd64-i386-xl-multivcpu pass
> test-amd64-amd64-pair pass
> test-amd64-i386-pair pass
> test-amd64-amd64-xl-sedf-pin pass
> test-amd64-amd64-pv blocked
> test-amd64-i386-pv blocked
> test-amd64-amd64-xl-sedf pass
> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
> test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
> test-amd64-i386-xl-winxpsp3-vcpus1 fail
> test-amd64-amd64-xl-qemut-winxpsp3 fail
> test-amd64-i386-xl-qemut-winxpsp3 fail
> test-amd64-amd64-xl-qemuu-winxpsp3 fail
> test-amd64-i386-xl-qemuu-winxpsp3 fail
> test-amd64-amd64-xl-winxpsp3 fail
> test-amd64-i386-xl-winxpsp3 fail
>
>
> ------------------------------------------------------------
> sg-report-flight on osstest.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
> http://www.chiark.greenend.org.uk/~xensrcts/logs
>
> Test harness code can be found at
> http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>
>
> Not pushing.
>
> ------------------------------------------------------------
> commit b021348231e942a342fd82e7a60193256236274d
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date: Fri Mar 28 13:48:39 2014 +0100
>
> public/platform.h: replace unsigned long with xen_ulong_t
>
> Replace unsigned long with xen_ulong_t in public/platform.h.
> Also replace unsigned int with uint32_t for clarity. It is safe because
> unsigned int are 4 byte sized and 4 byte aligned an all the supported
> architectures.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Keir Fraser <keir@xen.org>
>
> commit 226bc8ee4e0fd26bd3cbdb533eb447fdcd7a90bf
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:44:44 2014 +0100
>
> x86/vMTRR: pass domain to mtrr_*_msr_set()
>
> This is in preparation for the next patch, and mtrr_def_type_msr_set()
> and mtrr_fix_range_msr_set() in sync with mtrr_var_range_msr_set() in
> this regard.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
>
> commit 1f8b57779785bf9f55c16312bb1ec679929c314b
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:43:25 2014 +0100
>
> x86/EPT: relax treatment of APIC MFN
>
> There's no point in this being mapped UC by the guest due to using a
> respective PAT index - set the ignore-PAT flag to true.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
>
> commit 90e9c95f9713f413d6e7b2e19492d4e038a319b9
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:42:43 2014 +0100
>
> x86/EPT: also dump permissions and memory types
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
>
> commit 3d8d2bd048773ababfa65cc8781b9ab3f5cf0eb0
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:37:10 2014 +0100
>
> x86/EPT: simplification and cleanup
>
> - drop rsvd*_ prefixes from fields not really reserved anymore
> - replace odd uses of <expr> ? 1 : 0
> - drop pointless variables from ept_set_entry()
> - streamline IOMMU mirroring code in ept_set_entry()
> - don't open code is_epte_valid() (and properly use it when dumping)
> - streamline entry cloning in ept_split_super_page()
> - compact dumping code and output
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
>
> commit e5ae6eefdfbc1816b050d02998f69f0b78d5c814
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:36:19 2014 +0100
>
> x86/p2m: make p2m_change_type() behavior match p2m_change_entry_type_global()'s
>
> - don't reset access permissions
> - don't shatter super pages
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
>
> commit ef437690af8b75e6758dce77af75a22b63982883
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:33:34 2014 +0100
>
> x86/HVM: correct CPUID leaf 80000008 handling
>
> CPUID[80000008].EAX[23:16] have been given the meaning of the guest
> physical address restriction (in case it needs to be smaller than the
> host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
>
> Enforce a lower limit at the same time, as well as a fixed value for
> the virtual address bits, and zero for the guest physical address ones.
>
> In order for the vMTRR code to see these overrides we need to make it
> call hvm_cpuid() instead of domain_cpuid(), which in turn requires
> special casing (and relaxing) the controlling domain.
>
> This additionally should hide an ordering problem in the tools: Both
> xend and xl appear to be restoring a guest from its image before
> setting up the CPUID policy in the hypervisor, resulting in
> domain_cpuid() returning all zeros and hence the check in
> mtrr_var_range_msr_set() failing if the guest previously had more than
> the minimum 36 physical address bits.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
>
> commit 8bad6c5626129ffba04dbab3a38115b6f3669596
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:31:23 2014 +0100
>
> x86/HVM: fix preemption handling in do_hvm_op()
>
> Just like previously done for some mem-op hypercalls, undo preemption
> using the interface structures (altering it in ways the caller may not
> expect) and replace it by storing the continuation point in the high
> bits of sub-operation argument.
>
> This also changes the "nr" fields of struct xen_hvm_track_dirty_vram
> (operation already limited to 1Gb worth of pages) and struct
> xen_hvm_modified_memory to be only 32 bits wide, consistent with those
> of struct xen_set_mem{type,access}. If that's not acceptable for some
> reason, we'd need to shrink the HVMOP_op_bits (while still enforcing
> the [then higher] limit resulting from the need to be able to encode
> the continuation).
>
> Whether (and if so how) to adjust xc_hvm_track_dirty_vram(),
> xc_hvm_modified_memory(), xc_hvm_set_mem_type(), and
> xc_hvm_set_mem_access() to reflect the 32-bit restriction on "nr" is
> unclear: If the APIs need to remain stable, all four functions should
> probably check that there was no truncation. Preferably their
> parameters would be changed to uint32_t or unsigned int, though.
>
> As a minor cleanup, along with introducing the switch-wide "pfn" the
> redundant "d" is also being converted to a switch-wide one.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
>
> commit 8d134c2e12730a4a3dce9873f4671f6dd8860baf
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Fri Mar 28 13:30:10 2014 +0100
>
> x86/HVM: simplify do_hvm_op()
>
> - boundary checks in HVMOP_modified_memory, HVMOP_set_mem_type, and
> HVMOP_set_mem_access: all of these already check for overflow, so
> there's no need to range check the first _and_ last PFN (checking
> the last one suffices)
> - copying back interface structures that were previously copied from
> guest memory can use __copy_to_...(), since copy_from_...() already
> did the address range validation
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Tim Deegan <tim@xen.org>
> (qemu changes not included)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 25689: regressions - FAIL
2014-03-31 20:45 ` Boris Ostrovsky
@ 2014-04-01 8:38 ` Jan Beulich
2014-04-01 13:22 ` Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2014-04-01 8:38 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: xen-devel, xen.org, David Vrabel
>>> On 31.03.14 at 22:45, <boris.ostrovsky@oracle.com> wrote:
> On 03/31/2014 04:25 PM, xen.org wrote:
>> flight 25689 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/25689/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail REGR. vs. 25685
>> test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail REGR. vs. 25685
>> test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate.2 fail REGR. vs. 25685
>> test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
>> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 25685
>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
>> test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
>> test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
>
> I was just about to report a regression that may be what these failures
> also are.
>
> Looks like 8bad6c562 (x86/HVM: fix preemption handling in do_hvm_op() )
> broke qemu-traditional with HVM guests. Quite a few of
>
> (XEN) hvm.c:2762:d25v0 guest attempted write to read-only memory page.
> gfn=0x102, mfn=0x239086
I can see the change to be broken on 32-bit control domains (i.e.
Dom0 here), but I can't explain the breakage on 64-bit ones yet, nor
why only qemu-trad would be affected. Still this is enough reason for
me to revert it for the time being (and I can't really see how to
address the 32-bit issue without imposing further restrictions on the
permissible ranges for these sub-hypercalls).
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 25689: regressions - FAIL
2014-04-01 8:38 ` Jan Beulich
@ 2014-04-01 13:22 ` Jan Beulich
2014-04-01 14:41 ` Ian Campbell
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2014-04-01 13:22 UTC (permalink / raw)
To: xen-devel; +Cc: Boris Ostrovsky, xen.org, David Vrabel
>>> On 01.04.14 at 10:38, <JBeulich@suse.com> wrote:
>>>> On 31.03.14 at 22:45, <boris.ostrovsky@oracle.com> wrote:
>> On 03/31/2014 04:25 PM, xen.org wrote:
>>> flight 25689 xen-unstable real [real]
>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/25689/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>> test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail REGR. vs. 25685
>>> test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail REGR. vs. 25685
>>> test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate.2 fail REGR. vs. 25685
>>> test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
>>> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 25685
>>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
>>> test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
>>> test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
>>
>> I was just about to report a regression that may be what these failures
>> also are.
>>
>> Looks like 8bad6c562 (x86/HVM: fix preemption handling in do_hvm_op() )
>> broke qemu-traditional with HVM guests. Quite a few of
>>
>> (XEN) hvm.c:2762:d25v0 guest attempted write to read-only memory page.
>> gfn=0x102, mfn=0x239086
>
> I can see the change to be broken on 32-bit control domains (i.e.
> Dom0 here), but I can't explain the breakage on 64-bit ones yet, nor
> why only qemu-trad would be affected.
Found this one: In both HVMOP_modified_memory and
HVMOP_set_mem_type the "pfn" variable got incremented
twice. Looks like qemu-trad makes (more) use of the latter.
As to dealing with 32-bit callers, I see three possible routes:
- ignore the interface inconsistency (i.e. drop the patch altogether;
obviously not my preference)
- limit the permitted range for them to e.g. 27 bits (we need at least
5 bits for representing the operation itself, unless introducing
trickery; not too nice on its own considering future new sub-ops)
- introduce a new __HYPERVISOR_hvm_op (marking the current one
legacy) with one more (fake) argument: The caller doesn't need to
pass any specific value, but we're allowed to alter the register
contents, i.e. can store the continuation information there. This
would then go along with the range restriction above (but allow
those guests to still issue full-range requests).
Opinions or other ideas anyone?
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [xen-unstable test] 25689: regressions - FAIL
2014-04-01 13:22 ` Jan Beulich
@ 2014-04-01 14:41 ` Ian Campbell
2014-04-01 15:07 ` HVM op changes (was: Re: [xen-unstable test] 25689: regressions - FAIL) Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Ian Campbell @ 2014-04-01 14:41 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Boris Ostrovsky, xen.org, David Vrabel
On Tue, 2014-04-01 at 14:22 +0100, Jan Beulich wrote:
> >>> On 01.04.14 at 10:38, <JBeulich@suse.com> wrote:
> >>>> On 31.03.14 at 22:45, <boris.ostrovsky@oracle.com> wrote:
> >> On 03/31/2014 04:25 PM, xen.org wrote:
> >>> flight 25689 xen-unstable real [real]
> >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/25689/
> >>>
> >>> Regressions :-(
> >>>
> >>> Tests which did not succeed and are blocking,
> >>> including tests which could not be run:
> >>> test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail REGR. vs. 25685
> >>> test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail REGR. vs. 25685
> >>> test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate.2 fail REGR. vs. 25685
> >>> test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
> >>> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 25685
> >>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
> >>> test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 25685
> >>> test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25685
> >>
> >> I was just about to report a regression that may be what these failures
> >> also are.
> >>
> >> Looks like 8bad6c562 (x86/HVM: fix preemption handling in do_hvm_op() )
> >> broke qemu-traditional with HVM guests. Quite a few of
> >>
> >> (XEN) hvm.c:2762:d25v0 guest attempted write to read-only memory page.
> >> gfn=0x102, mfn=0x239086
> >
> > I can see the change to be broken on 32-bit control domains (i.e.
> > Dom0 here), but I can't explain the breakage on 64-bit ones yet, nor
> > why only qemu-trad would be affected.
>
> Found this one: In both HVMOP_modified_memory and
> HVMOP_set_mem_type the "pfn" variable got incremented
> twice. Looks like qemu-trad makes (more) use of the latter.
>
> As to dealing with 32-bit callers, I see three possible routes:
> - ignore the interface inconsistency (i.e. drop the patch altogether;
> obviously not my preference)
> - limit the permitted range for them to e.g. 27 bits (we need at least
> 5 bits for representing the operation itself, unless introducing
> trickery; not too nice on its own considering future new sub-ops)
> - introduce a new __HYPERVISOR_hvm_op (marking the current one
> legacy) with one more (fake) argument: The caller doesn't need to
> pass any specific value, but we're allowed to alter the register
> contents, i.e. can store the continuation information there. This
> would then go along with the range restriction above (but allow
> those guests to still issue full-range requests).
>
> Opinions or other ideas anyone?
Did you mean to CC Keir and/or Tim (who may not read this thread based
on the title).
2^27 pages seems like a plenty large enough reasonable limit for a batch
size to me, although maybe 5 bits for the op is a bit tight given we are
at 16 right now?
Could you do continuations at some larger granularity (e.g. 2MB) and
save some bits that way?
With your third idea it might actually be quite nice and natural to
split the hvm_op interface into parts anyway, for guest vs. toolstack
(vs. device model?() accessible functionality.
The guest accessible stuff could stay on the current op with the other
uses being deprecated.
Ian.
^ permalink raw reply [flat|nested] 6+ messages in thread
* HVM op changes (was: Re: [xen-unstable test] 25689: regressions - FAIL)
2014-04-01 14:41 ` Ian Campbell
@ 2014-04-01 15:07 ` Jan Beulich
0 siblings, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2014-04-01 15:07 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Tim Deegan, xen.org, DavidVrabel, xen-devel,
Boris Ostrovsky
>>> On 01.04.14 at 16:41, <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-04-01 at 14:22 +0100, Jan Beulich wrote:
>> >>> On 01.04.14 at 10:38, <JBeulich@suse.com> wrote:
>> >>>> On 31.03.14 at 22:45, <boris.ostrovsky@oracle.com> wrote:
>> >> On 03/31/2014 04:25 PM, xen.org wrote:
>> >>> flight 25689 xen-unstable real [real]
>> >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/25689/
>> >>>
>> >>> Regressions :-(
>> >>>
>> >>> Tests which did not succeed and are blocking,
>> >>> including tests which could not be run:
>> >>> test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail REGR. vs.
> 25685
>> >>> test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail REGR. vs.
> 25685
>> >>> test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate.2 fail REGR. vs.
> 25685
>> >>> test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs.
> 25685
>> >>> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs.
> 25685
>> >>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs.
> 25685
>> >>> test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs.
> 25685
>> >>> test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs.
> 25685
>> >>
>> >> I was just about to report a regression that may be what these failures
>> >> also are.
>> >>
>> >> Looks like 8bad6c562 (x86/HVM: fix preemption handling in do_hvm_op() )
>> >> broke qemu-traditional with HVM guests. Quite a few of
>> >>
>> >> (XEN) hvm.c:2762:d25v0 guest attempted write to read-only memory page.
>> >> gfn=0x102, mfn=0x239086
>> >
>> > I can see the change to be broken on 32-bit control domains (i.e.
>> > Dom0 here), but I can't explain the breakage on 64-bit ones yet, nor
>> > why only qemu-trad would be affected.
>>
>> Found this one: In both HVMOP_modified_memory and
>> HVMOP_set_mem_type the "pfn" variable got incremented
>> twice. Looks like qemu-trad makes (more) use of the latter.
>>
>> As to dealing with 32-bit callers, I see three possible routes:
>> - ignore the interface inconsistency (i.e. drop the patch altogether;
>> obviously not my preference)
>> - limit the permitted range for them to e.g. 27 bits (we need at least
>> 5 bits for representing the operation itself, unless introducing
>> trickery; not too nice on its own considering future new sub-ops)
>> - introduce a new __HYPERVISOR_hvm_op (marking the current one
>> legacy) with one more (fake) argument: The caller doesn't need to
>> pass any specific value, but we're allowed to alter the register
>> contents, i.e. can store the continuation information there. This
>> would then go along with the range restriction above (but allow
>> those guests to still issue full-range requests).
>>
>> Opinions or other ideas anyone?
>
> Did you mean to CC Keir and/or Tim (who may not read this thread based
> on the title).
Indeed I should have, and have done so now.
> 2^27 pages seems like a plenty large enough reasonable limit for a batch
> size to me, although maybe 5 bits for the op is a bit tight given we are
> at 16 right now?
Right, that's what I was thinking too.
> Could you do continuations at some larger granularity (e.g. 2MB) and
> save some bits that way?
Right - I had this idea in the morning, but forgot about it again by
time I got to write that mail.
> With your third idea it might actually be quite nice and natural to
> split the hvm_op interface into parts anyway, for guest vs. toolstack
> (vs. device model?() accessible functionality.
>
> The guest accessible stuff could stay on the current op with the other
> uses being deprecated.
That's a pretty neat idea, I'll see to carry that out unless others
object violently.
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-01 15:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-31 20:25 [xen-unstable test] 25689: regressions - FAIL xen.org
2014-03-31 20:45 ` Boris Ostrovsky
2014-04-01 8:38 ` Jan Beulich
2014-04-01 13:22 ` Jan Beulich
2014-04-01 14:41 ` Ian Campbell
2014-04-01 15:07 ` HVM op changes (was: Re: [xen-unstable test] 25689: regressions - FAIL) 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.