RE: [Xen-ia64-devel] [PATCH] This is the first patch to merge vcpu.c

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

I forgot to add: This kind of bug is VERY difficult to
find and fix because there is no obvious trigger to
start debugging.  With the segmentation fault, the
delivery of a fault is rare enough that one can
add code to the hypervisor to printf info when it
happens, but if a user app (especially something
as large and complex as a compiler) just goes into
an infinite loop, there's nothing as a trigger.

If you can reproduce this, I'd suggest breaking
down the patch into smaller patches to see what
specific change causes the problem.  If I just
accept the patch, it will be much harder to track
the problem down later. 

> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Magenheimer, Dan (HP Labs Fort Collins)
> Sent: Wednesday, September 14, 2005 8:09 PM
> To: Xu, Anthony
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch 
> to merge vcpu.c
> 
> 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"
> behavior before. 
> 
> > -----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.
> > 
> > Thanks
> > Anthony
> > 
> > >-----Original Message-----
> > >From: Magenheimer, Dan (HP Labs Fort Collins) 
> > [mailto:dan.magenheimer@xxxxxx]
> > >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.
> > >
> > >Dan
> > >
> > >
> > >> -----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[4] will not exist, we
> > >> will all use vcpu->arch.insvc[4]
> > >> 4. Cleaned up some unused structure members and codes.
> > >>
> > >>
> > >> Signed-off-by Anthony Xu <Anthony.xu@xxxxxxxxx>
> > >>
> > >> Thanks,
> > >> Anthony
> > >>
> > 
> 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel