From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [xen-unstable test] 25689: regressions - FAIL Date: Mon, 31 Mar 2014 16:45:44 -0400 Message-ID: <5339D3F8.30105@oracle.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen.org" Cc: xen-devel@lists.xensource.com, David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 > Jan Beulich > Keir Fraser > Stefano Stabellini > ------------------------------------------------------------ > > 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 > 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 > Acked-by: Ian Campbell > Acked-by: Keir Fraser > > commit 226bc8ee4e0fd26bd3cbdb533eb447fdcd7a90bf > Author: Jan Beulich > 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 > Reviewed-by: Tim Deegan > > commit 1f8b57779785bf9f55c16312bb1ec679929c314b > Author: Jan Beulich > 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 > Reviewed-by: Tim Deegan > > commit 90e9c95f9713f413d6e7b2e19492d4e038a319b9 > Author: Jan Beulich > Date: Fri Mar 28 13:42:43 2014 +0100 > > x86/EPT: also dump permissions and memory types > > Signed-off-by: Jan Beulich > Reviewed-by: Tim Deegan > > commit 3d8d2bd048773ababfa65cc8781b9ab3f5cf0eb0 > Author: Jan Beulich > 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 ? 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 > Reviewed-by: Tim Deegan > > commit e5ae6eefdfbc1816b050d02998f69f0b78d5c814 > Author: Jan Beulich > 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 > Reviewed-by: Tim Deegan > > commit ef437690af8b75e6758dce77af75a22b63982883 > Author: Jan Beulich > 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 > Reviewed-by: Tim Deegan > > commit 8bad6c5626129ffba04dbab3a38115b6f3669596 > Author: Jan Beulich > 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 > Reviewed-by: Tim Deegan > > commit 8d134c2e12730a4a3dce9873f4671f6dd8860baf > Author: Jan Beulich > 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 > Reviewed-by: Andrew Cooper > Reviewed-by: Tim Deegan > (qemu changes not included) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel