[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Wed, 14 Sep 2005 19:08:38 -0700
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 15 Sep 2005 02:07:12 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcW3k8hGa6d5du+US6qlqScOINw+uABUwSAgACpcQhAAAm0VIA==
  • Thread-topic: [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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.