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

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

Script attached.  It's not pretty and will need
to be adapted for a different environment, but
I've used the same script for a long time so
that I can compare results.

The privcnt lines can be removed... I can't find
the source for privcnt, but it is probably the
same as what I posted here:

http://lists.xensource.com/archives/html/xen-devel/2005-03/msg00216.html 

> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx] 
> Sent: Wednesday, September 14, 2005 8:38 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
> 
> Thanks for your suggestion, 
> Please send me your buildlinux script, see whether I can reproduce it.
> And I can do this stress_test before I send patch..
> 
> Thanks
> Anthony
> 
> 
> 
> >-----Original Message-----
> >From: Magenheimer, Dan (HP Labs Fort Collins) 
> [mailto:dan.magenheimer@xxxxxx]
> >Sent: 2005å9æ15æ 10:18
> >To: Xu, Anthony
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-ia64-devel] [PATCH] This is the first 
> patch to merge vcpu.c
> >
> >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
> >> > >>
> >> >
> >>
>

Attachment: buildlinux
Description: buildlinux

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