flight 16788 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 7 windows-install fail REGR. vs. 16772
test-amd64-i386-win 7 windows-install fail REGR. vs. 16772
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 16772
test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 16772
test-amd64-i386-xend-winxpsp3 7 windows-install fail REGR. vs. 16772
Tests which are failing intermittently (not blocking):
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail pass in 16778
test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail pass in 16778
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail in 16778 pass in
16864-bisect
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf 5 xen-boot fail like 16772
test-amd64-amd64-xl-sedf-pin 7 debian-install fail blocked in 16772
test-amd64-amd64-xl-qemut-win 7 windows-install fail like 16772
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-qemut-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-qemut-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-qemut-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
version targeted for testing:
xen 2f80ac9c0e8fe117b3e9cf71f799b482c6ca312f
baseline version:
xen ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
------------------------------------------------------------
People who touched revisions under test:
Ian Jackson <ian.jackson@eu.citrix.com>
Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd 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-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
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 fail
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-qemut-win-vcpus1 fail
test-amd64-i386-xl-qemut-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-amd64-amd64-qemut-win fail
test-amd64-i386-qemut-win fail
test-amd64-amd64-xl-qemut-win fail
test-amd64-amd64-xl-win fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.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 2f80ac9c0e8fe117b3e9cf71f799b482c6ca312f
Author: Olaf Hering <olaf@aepfle.de>
Date: Wed Feb 27 14:16:36 2013 +0000
tools/xentoollog: update tty detection in stdiostream_progress
As suggested by IanJ:
Check isatty only once to preserve the errno of ->progress users, and to
reduce the noice in strace output.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)
>>> On 02.03.13 at 13:34, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 16788 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/16788/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-xend-qemut-winxpsp3 7 windows-install fail REGR. vs. 16772 > test-amd64-i386-win 7 windows-install fail REGR. vs. 16772So this (and presumably other Windows failures too) is apparently a regression from 703ac3abcfc5f649c038070867ee12c67f730548 ("x86: introduce create_perdomain_mapping()"), running into emulate_map_dest()''s /* Hack: we map the pages into the vcpu''s LDT space, since we * know that we''re not going to need the LDT for HVM guests, * and only HVM guests are allowed unaligned writes. */ ASSERT(is_hvm_vcpu(v)); map = (void *)LDT_VIRT_START(v); offset = l1_linear_offset((unsigned long) map); l1e_write(&__linear_l1_table[offset], l1e_from_pfn(mfn_x(sh_ctxt->mfn1), __PAGE_HYPERVISOR)); l1e_write(&__linear_l1_table[offset + 1], l1e_from_pfn(mfn_x(sh_ctxt->mfn2), __PAGE_HYPERVISOR)); flush_tlb_local(); map += (vaddr & ~PAGE_MASK); Question - is there really no better way than this to deal with cross page emulated writes? If not, I''ll have to figure out where in the shadow initialization code a call to create_perdomain_mapping() would need to be added. Jan> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 16772 > test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 16772 > test-amd64-i386-xend-winxpsp3 7 windows-install fail REGR. vs. 16772
At 10:57 +0000 on 04 Mar (1362394626), Jan Beulich wrote:> >>> On 02.03.13 at 13:34, xen.org <ian.jackson@eu.citrix.com> wrote: > > flight 16788 xen-unstable real [real] > > http://www.chiark.greenend.org.uk/~xensrcts/logs/16788/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-i386-xend-qemut-winxpsp3 7 windows-install fail REGR. vs. 16772 > > test-amd64-i386-win 7 windows-install fail REGR. vs. 16772 > > So this (and presumably other Windows failures too) is apparently > a regression from 703ac3abcfc5f649c038070867ee12c67f730548 > ("x86: introduce create_perdomain_mapping()"), running into > emulate_map_dest()''s > > /* Hack: we map the pages into the vcpu''s LDT space, since we > * know that we''re not going to need the LDT for HVM guests, > * and only HVM guests are allowed unaligned writes. */ > ASSERT(is_hvm_vcpu(v)); > map = (void *)LDT_VIRT_START(v); > offset = l1_linear_offset((unsigned long) map); > l1e_write(&__linear_l1_table[offset], > l1e_from_pfn(mfn_x(sh_ctxt->mfn1), __PAGE_HYPERVISOR)); > l1e_write(&__linear_l1_table[offset + 1], > l1e_from_pfn(mfn_x(sh_ctxt->mfn2), __PAGE_HYPERVISOR)); > flush_tlb_local(); > map += (vaddr & ~PAGE_MASK); > > Question - is there really no better way than this to deal with > cross page emulated writes?There probably is -- all that''s wanted here is two mappings that are guaranteed to be contiguous in virtual address. The LDT slots were available; it would have been better to document this use where LDT_VIRT_START is defined, though. AFAICT, we''ll need to: - cause some equivalent pair of PTEs to be available (either per-cpu or per-vcpu); or - add a map_two_domain_pages() function to use the mapcache for this; or - rework the emulated accesses not to need contiguous mappings (but I don''t fancy doing a page-crossing cmpxchg in that case). Cheers, Tim.
>>> On 04.03.13 at 12:12, Tim Deegan <tim@xen.org> wrote: > At 10:57 +0000 on 04 Mar (1362394626), Jan Beulich wrote: >> >>> On 02.03.13 at 13:34, xen.org <ian.jackson@eu.citrix.com> wrote: >> > flight 16788 xen-unstable real [real] >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/16788/ >> > >> > Regressions :-( >> > >> > Tests which did not succeed and are blocking, >> > including tests which could not be run: >> > test-amd64-i386-xend-qemut-winxpsp3 7 windows-install fail REGR. vs. 16772 >> > test-amd64-i386-win 7 windows-install fail REGR. vs. 16772 >> >> So this (and presumably other Windows failures too) is apparently >> a regression from 703ac3abcfc5f649c038070867ee12c67f730548 >> ("x86: introduce create_perdomain_mapping()"), running into >> emulate_map_dest()''s >> >> /* Hack: we map the pages into the vcpu''s LDT space, since we >> * know that we''re not going to need the LDT for HVM guests, >> * and only HVM guests are allowed unaligned writes. */ >> ASSERT(is_hvm_vcpu(v)); >> map = (void *)LDT_VIRT_START(v); >> offset = l1_linear_offset((unsigned long) map); >> l1e_write(&__linear_l1_table[offset], >> l1e_from_pfn(mfn_x(sh_ctxt->mfn1), __PAGE_HYPERVISOR)); >> l1e_write(&__linear_l1_table[offset + 1], >> l1e_from_pfn(mfn_x(sh_ctxt->mfn2), __PAGE_HYPERVISOR)); >> flush_tlb_local(); >> map += (vaddr & ~PAGE_MASK); >> >> Question - is there really no better way than this to deal with >> cross page emulated writes? > > There probably is -- all that''s wanted here is two mappings that are > guaranteed to be contiguous in virtual address. The LDT slots were > available; it would have been better to document this use where > LDT_VIRT_START is defined, though. > > AFAICT, we''ll need to: > - cause some equivalent pair of PTEs to be available (either per-cpu or > per-vcpu); or > - add a map_two_domain_pages() function to use the mapcache for this; orWould vmap() do? Or do we expect this code path to be performance sensitive? Jan> - rework the emulated accesses not to need contiguous mappings (but I > don''t fancy doing a page-crossing cmpxchg in that case). > > Cheers, > > Tim.
At 11:29 +0000 on 04 Mar (1362396574), Jan Beulich wrote:> >>> On 04.03.13 at 12:12, Tim Deegan <tim@xen.org> wrote: > > At 10:57 +0000 on 04 Mar (1362394626), Jan Beulich wrote: > >> Question - is there really no better way than this to deal with > >> cross page emulated writes? > > > > There probably is -- all that''s wanted here is two mappings that are > > guaranteed to be contiguous in virtual address. The LDT slots were > > available; it would have been better to document this use where > > LDT_VIRT_START is defined, though. > > > > AFAICT, we''ll need to: > > - cause some equivalent pair of PTEs to be available (either per-cpu or > > per-vcpu); or > > - add a map_two_domain_pages() function to use the mapcache for this; or > > Would vmap() do? Or do we expect this code path to be performance > sensitive?I can''t really tell what vmap() is for, since it seems to have no documentation, and the checkin description just says "implement vmap()". But it looks plausible, and emulating page-crossing writes oughtn''t to be performance-sensitive. Tim.
>>> On 04.03.13 at 12:45, Tim Deegan <tim@xen.org> wrote: > At 11:29 +0000 on 04 Mar (1362396574), Jan Beulich wrote: >> >>> On 04.03.13 at 12:12, Tim Deegan <tim@xen.org> wrote: >> > At 10:57 +0000 on 04 Mar (1362394626), Jan Beulich wrote: >> >> Question - is there really no better way than this to deal with >> >> cross page emulated writes? >> > >> > There probably is -- all that''s wanted here is two mappings that are >> > guaranteed to be contiguous in virtual address. The LDT slots were >> > available; it would have been better to document this use where >> > LDT_VIRT_START is defined, though. >> > >> > AFAICT, we''ll need to: >> > - cause some equivalent pair of PTEs to be available (either per-cpu or >> > per-vcpu); or >> > - add a map_two_domain_pages() function to use the mapcache for this; or >> >> Would vmap() do? Or do we expect this code path to be performance >> sensitive? > > I can''t really tell what vmap() is for, since it seems to have no > documentation, and the checkin description just says "implement vmap()". > But it looks plausible, and emulating page-crossing writes oughtn''t to > be performance-sensitive.Like this then (compile tested only so far): --- a/xen/arch/x86/mm/shadow/multi.c +++ b/xen/arch/x86/mm/shadow/multi.c @@ -4611,7 +4611,6 @@ static void *emulate_map_dest(struct vcp u32 bytes, struct sh_emulate_ctxt *sh_ctxt) { - unsigned long offset; void *map = NULL; sh_ctxt->mfn1 = emulate_gva_to_mfn(v, vaddr, sh_ctxt); @@ -4643,6 +4642,8 @@ static void *emulate_map_dest(struct vcp } else { + unsigned long mfns[2]; + /* Cross-page emulated writes are only supported for HVM guests; * PV guests ought to know better */ if ( !is_hvm_vcpu(v) ) @@ -4660,17 +4661,11 @@ static void *emulate_map_dest(struct vcp /* Cross-page writes mean probably not a pagetable */ sh_remove_shadows(v, sh_ctxt->mfn2, 0, 0 /* Slow, can fail */ ); - /* Hack: we map the pages into the vcpu''s LDT space, since we - * know that we''re not going to need the LDT for HVM guests, - * and only HVM guests are allowed unaligned writes. */ - ASSERT(is_hvm_vcpu(v)); - map = (void *)LDT_VIRT_START(v); - offset = l1_linear_offset((unsigned long) map); - l1e_write(&__linear_l1_table[offset], - l1e_from_pfn(mfn_x(sh_ctxt->mfn1), __PAGE_HYPERVISOR)); - l1e_write(&__linear_l1_table[offset + 1], - l1e_from_pfn(mfn_x(sh_ctxt->mfn2), __PAGE_HYPERVISOR)); - flush_tlb_local(); + mfns[0] = mfn_x(sh_ctxt->mfn1); + mfns[1] = mfn_x(sh_ctxt->mfn2); + map = vmap(mfns, 2); + if ( !map ) + return MAPPING_UNHANDLEABLE; map += (vaddr & ~PAGE_MASK); } @@ -4748,14 +4743,8 @@ static void emulate_unmap_dest(struct vc if ( unlikely(mfn_valid(sh_ctxt->mfn2)) ) { - unsigned long offset; paging_mark_dirty(v->domain, mfn_x(sh_ctxt->mfn2)); - /* Undo the hacky two-frame contiguous map. */ - ASSERT(((unsigned long) addr & PAGE_MASK) == LDT_VIRT_START(v)); - offset = l1_linear_offset((unsigned long) addr); - l1e_write(&__linear_l1_table[offset], l1e_empty()); - l1e_write(&__linear_l1_table[offset + 1], l1e_empty()); - flush_tlb_all(); + vunmap(addr - ((unsigned long)addr & ~PAGE_MASK)); } else sh_unmap_domain_page(addr); Jan
At 12:06 +0000 on 04 Mar (1362398796), Jan Beulich wrote:> >>> On 04.03.13 at 12:45, Tim Deegan <tim@xen.org> wrote: > > At 11:29 +0000 on 04 Mar (1362396574), Jan Beulich wrote: > >> >>> On 04.03.13 at 12:12, Tim Deegan <tim@xen.org> wrote: > >> > At 10:57 +0000 on 04 Mar (1362394626), Jan Beulich wrote: > >> >> Question - is there really no better way than this to deal with > >> >> cross page emulated writes? > >> > > >> > There probably is -- all that''s wanted here is two mappings that are > >> > guaranteed to be contiguous in virtual address. The LDT slots were > >> > available; it would have been better to document this use where > >> > LDT_VIRT_START is defined, though. > >> > > >> > AFAICT, we''ll need to: > >> > - cause some equivalent pair of PTEs to be available (either per-cpu or > >> > per-vcpu); or > >> > - add a map_two_domain_pages() function to use the mapcache for this; or > >> > >> Would vmap() do? Or do we expect this code path to be performance > >> sensitive? > > > > I can''t really tell what vmap() is for, since it seems to have no > > documentation, and the checkin description just says "implement vmap()". > > But it looks plausible, and emulating page-crossing writes oughtn''t to > > be performance-sensitive. > > Like this then (compile tested only so far):> @@ -4748,14 +4743,8 @@ static void emulate_unmap_dest(struct vc > > if ( unlikely(mfn_valid(sh_ctxt->mfn2)) ) > { > - unsigned long offset; > paging_mark_dirty(v->domain, mfn_x(sh_ctxt->mfn2)); > - /* Undo the hacky two-frame contiguous map. */ > - ASSERT(((unsigned long) addr & PAGE_MASK) == LDT_VIRT_START(v)); > - offset = l1_linear_offset((unsigned long) addr); > - l1e_write(&__linear_l1_table[offset], l1e_empty()); > - l1e_write(&__linear_l1_table[offset + 1], l1e_empty()); > - flush_tlb_all(); > + vunmap(addr - ((unsigned long)addr & ~PAGE_MASK));I''d prefer ''vunmap((void *)((unsigned long) addr & PAGE_MASK));''. Otherwise, Acked-by: Tim Deegan <tim@xen.org> Cheers, Tim.
>>> On 04.03.13 at 13:42, Tim Deegan <tim@xen.org> wrote: > At 12:06 +0000 on 04 Mar (1362398796), Jan Beulich wrote: >> >>> On 04.03.13 at 12:45, Tim Deegan <tim@xen.org> wrote: >> > At 11:29 +0000 on 04 Mar (1362396574), Jan Beulich wrote: >> >> >>> On 04.03.13 at 12:12, Tim Deegan <tim@xen.org> wrote: >> >> > At 10:57 +0000 on 04 Mar (1362394626), Jan Beulich wrote: >> >> >> Question - is there really no better way than this to deal with >> >> >> cross page emulated writes? >> >> > >> >> > There probably is -- all that''s wanted here is two mappings that are >> >> > guaranteed to be contiguous in virtual address. The LDT slots were >> >> > available; it would have been better to document this use where >> >> > LDT_VIRT_START is defined, though. >> >> > >> >> > AFAICT, we''ll need to: >> >> > - cause some equivalent pair of PTEs to be available (either per-cpu or >> >> > per-vcpu); or >> >> > - add a map_two_domain_pages() function to use the mapcache for this; or >> >> >> >> Would vmap() do? Or do we expect this code path to be performance >> >> sensitive? >> > >> > I can''t really tell what vmap() is for, since it seems to have no >> > documentation, and the checkin description just says "implement vmap()". >> > But it looks plausible, and emulating page-crossing writes oughtn''t to >> > be performance-sensitive. >> >> Like this then (compile tested only so far): > >> @@ -4748,14 +4743,8 @@ static void emulate_unmap_dest(struct vc >> >> if ( unlikely(mfn_valid(sh_ctxt->mfn2)) ) >> { >> - unsigned long offset; >> paging_mark_dirty(v->domain, mfn_x(sh_ctxt->mfn2)); >> - /* Undo the hacky two-frame contiguous map. */ >> - ASSERT(((unsigned long) addr & PAGE_MASK) == LDT_VIRT_START(v)); >> - offset = l1_linear_offset((unsigned long) addr); >> - l1e_write(&__linear_l1_table[offset], l1e_empty()); >> - l1e_write(&__linear_l1_table[offset + 1], l1e_empty()); >> - flush_tlb_all(); >> + vunmap(addr - ((unsigned long)addr & ~PAGE_MASK)); > > I''d prefer ''vunmap((void *)((unsigned long) addr & PAGE_MASK));''.That''s fine by me, just wanted to avoid needing to cast twice.> Otherwise, Acked-by: Tim Deegan <tim@xen.org>Having some problem testing this - not with the change itself, but with something else that I don''t understand yet (XENMEM_add_to_physmap:XENMAPSPACE_grant_table failing during domain construction, but only when hap=0 in the config file). Jan
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 16788: regressions
- FAIL"):> So this (and presumably other Windows failures too) is apparently
> a regression from 703ac3abcfc5f649c038070867ee12c67f730548
> ("x86: introduce create_perdomain_mapping()"), running into
> emulate_map_dest()''s
FYI indeed the bisector looks like it''s going to finger 703ac3.
It''s
just making sure...
Ian.
>>> On 04.03.13 at 14:20, "Jan Beulich" <JBeulich@suse.com> wrote: > Having some problem testing this - not with the change itself, > but with something else that I don''t understand yet > (XENMEM_add_to_physmap:XENMAPSPACE_grant_table failing > during domain construction, but only when hap=0 in the config > file).So this is due to a number of factors: shadow_enable() calls sh_set_allocation() with 1024 as the page count argument. My guest has 8 vCPU-s (and 2G or memory), causing (once all vCPU-s got created) shadow_min_acceptable_pages() to return 9*128=1152. Which means that there won''t ever be a success return from shadow_alloc_p2m_page(). Lowering the vCPU count to 2 doesn''t help - the now available portion of pages will all be consumed for p2m, and by the time the grant table physmap insertion happens there''s again nothing left. Also lowering memory size to 512M did finally help. So apparently xl doesn''t set the shadow size early enough, as by the time domain creation fails, I can''t observe any invocation of shadow_domctl(), i.e. also not libxl__arch_domain_create()''s XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION. That''s all very unsatisfying, the more with the failure not easily being recognizable as an out of (shadow) memory related one. So in the end I spent a couple of hours figuring all this out, rather than just running a simple test to verify the change above (in order to commit it quickly, so that hopefully the test failures would get addressed). And in the end, Tim, it doesn''t look like Linux HVM guests exercise the cross-page-boundary emulation path, so I can''t really test the code. Shall I put it in nevertheless, or would you be able to give this a go beforehand? Jan
At 16:34 +0000 on 04 Mar (1362414893), Jan Beulich wrote:> >>> On 04.03.13 at 14:20, "Jan Beulich" <JBeulich@suse.com> wrote: > > Having some problem testing this - not with the change itself, > > but with something else that I don''t understand yet > > (XENMEM_add_to_physmap:XENMAPSPACE_grant_table failing > > during domain construction, but only when hap=0 in the config > > file). > > So this is due to a number of factors: > > shadow_enable() calls sh_set_allocation() with 1024 as the page > count argument. My guest has 8 vCPU-s (and 2G or memory), > causing (once all vCPU-s got created) shadow_min_acceptable_pages() > to return 9*128=1152. Which means that there won''t ever be a > success return from shadow_alloc_p2m_page().Argh. sh_set_allocation() deliberately leaves (d->tot_pages / 256) of overhead on top of shadow_min_acceptable_pages(), but this first call happens before tot_pages is set. :(> Lowering the > vCPU count to 2 doesn''t help - the now available portion of pages > will all be consumed for p2m, and by the time the grant table > physmap insertion happens there''s again nothing left. Also > lowering memory size to 512M did finally help. > > So apparently xl doesn''t set the shadow size early enough, as by > the time domain creation fails, I can''t observe any invocation of > shadow_domctl(), i.e. also not libxl__arch_domain_create()''s > XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION.Hmmm. libxl__arch_domain_create() seems to be called from domcreate_attach_pci(), of all places -- oh, because the whole process is a series of tail-calls -- and that''s very late in domain build. I''m pretty sure xend allocated shadow RAM up front. Or maybe we''re only now getting to see VMs big enough that this is a problem.> That''s all very unsatisfying, the more with the failure not easily > being recognizable as an out of (shadow) memory related one. SoHow annoying. I''ll add at least a one-time console warning and look into some more sensible error propagation> in the end I spent a couple of hours figuring all this out, rather > than just running a simple test to verify the change above (in > order to commit it quickly, so that hopefully the test failures would > get addressed). > > And in the end, Tim, it doesn''t look like Linux HVM guests exercise > the cross-page-boundary emulation path, so I can''t really test the > code. Shall I put it in nevertheless, or would you be able to give > this a go beforehand?Unfortunately there''s no chance I can do any testing this week before Thursday. I think the patch should go in anyway -- it''s not going to make the situation any worse for VMs that do hit that path. Tim.
>>> On 04.03.13 at 18:14, Tim Deegan <tim@xen.org> wrote: > At 16:34 +0000 on 04 Mar (1362414893), Jan Beulich wrote: >> So apparently xl doesn''t set the shadow size early enough, as by >> the time domain creation fails, I can''t observe any invocation of >> shadow_domctl(), i.e. also not libxl__arch_domain_create()''s >> XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION. > > Hmmm. libxl__arch_domain_create() seems to be called from > domcreate_attach_pci(), of all places -- oh, because the whole > process is a series of tail-calls -- and that''s very late in > domain build. I''m pretty sure xend allocated shadow RAM up front.While I having looked at this last must date back a couple of years, I''m also relatively certain that xend did this earlier.> Or maybe we''re only now getting to see VMs big enough that this is a > problem.Less likely. But presumably the test system should be using bigger guests, or have a case of a bigger guest added? Ian - any chance you could look into both the xl and the test suite aspects?>> That''s all very unsatisfying, the more with the failure not easily >> being recognizable as an out of (shadow) memory related one. > > How annoying. I''ll add at least a one-time console warning and look > into some more sensible error propagationThanks!>> And in the end, Tim, it doesn''t look like Linux HVM guests exercise >> the cross-page-boundary emulation path, so I can''t really test the >> code. Shall I put it in nevertheless, or would you be able to give >> this a go beforehand? > > Unfortunately there''s no chance I can do any testing this week before > Thursday. I think the patch should go in anyway -- it''s not going to > make the situation any worse for VMs that do hit that path.Okay, committed - after having sent the mail I too realized that having the patch in won''t make matters worse. Jan