Yes, definitely, I run my stress test before checking
in any change. I do periodically see a segmentation
fault (ever since about mid-July when the first round
of merge changes went in) that I haven't been able
to isolate yet, but have never seen this "freeze"
> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> Sent: Wednesday, September 14, 2005 7:03 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch
> to merge vcpu.c
> Hi Dan,
> I haven't stress-tested my patch, my patch almost doesn't
> touch xeno code,
> I am curious have you done the same stress-test on dom0
> without my patch?
> I think we'd better setup the infrastructure ( domU and VTdom
> up) first, then we will come back to make all this stable.
> >-----Original Message-----
> >From: Magenheimer, Dan (HP Labs Fort Collins)
> >Sent: 2005年9月14日 12:48
> >To: Xu, Anthony
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-ia64-devel] [PATCH] This is the first
> patch to merge vcpu.c
> >Hi Anthony --
> >I tried your patch. It applies cleanly and compiles
> >cleanly. However, I am seeing problems when testing it.
> >I run a script that builds linux ten times as
> >a stress test. During this test, twice, gcc has
> >frozen or gotten into an infinite loop; I'm not
> >really sure other than it continues to eat up CPU
> >time and not make forward progress. Other times
> >building linux completes OK.
> >Have you stress-tested the patch on your system?
> >I would be curious whether you can reproduce it.
> >I can send you my buildlinux script if you like.
> >> -----Original Message-----
> >> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> >> Sent: Monday, September 12, 2005 6:28 AM
> >> To: Magenheimer, Dan (HP Labs Fort Collins)
> >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: [Xen-ia64-devel] [PATCH] This is the first patch to
> >> merge vcpu.c
> >> Dan,
> >> This patch is based on ver 6723. And definitely I can boot
> >> dom0 with this patch.
> >> Following things are done in this patch.
> >> 1. Merge structure pt_reg.
> >> 2. Though vcpu_info structure has been merged, non-vt domain
> >> used pointer vcpu->vcpu_info->arch.privregs, and vt domain
> >> used pointer vcpu->arch.arch_vmx.vpd, the value of these two
> >> pointers are different, that means vt and non-vt domain still
> >> use different privileged registers pages, in this case, we
> >> can't merge vcpu.c, so I merged these two pointer, and put it
> >> at vcpu->arch.privregs. vcpu->vcpu_info->arch.privregs and
> >> vcpu->arch.arch_vmx.vpd will not exist. Why put it at
> >> vcpu->arch.privregs? 1. There will be one less pointer
> >> unreferenced when accessing this privileged registers page.
> >> 2. vcpu->vcpu_info can be accessed by guest, but guest can't
> >> access privileged registers page through this address, guest
> >> can access this privileged page only through another special
> >> mapping. So there is no need to expose this pointer to guest
> >> by putting it in vcpu->vcpu_info structure. All accesses to
> >> this page is through VCPU(vcpu,y) macro,
> >> 3. Merged following functions.
> >> Vcpu_set/get_(interruption control registers from cr16
> >> to cr25), corresponding functions vmx_vcpu_set/get_***
> will not exist.
> >> Vcpu->arch.arch_vmx.in_service will not exist, we
> >> will all use vcpu->arch.insvc
> >> 4. Cleaned up some unused structure members and codes.
> >> Signed-off-by Anthony Xu <Anthony.xu@xxxxxxxxx>
> >> Thanks,
> >> Anthony
Xen-ia64-devel mailing list