WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch to merge vcpu.c
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Fri, 16 Sep 2005 11:52:52 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 16 Sep 2005 03:50:35 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcW3k8hGa6d5du+US6qlqScOINw+uABUwSAgACpcQhAAAm0VIAAASZ4gAADGmCAAAm67sAAyZZgA
Thread-topic: [Xen-ia64-devel] [PATCH] This is the first patch to merge vcpu.c
Dan,

The build-test is very slow; I am testing the latest xenolinux using your 
script,
It cost 3 hours for 4 times of building.

Thanks
Anthony

>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>Sent: 2005年9月15日 11:53
>To: Xu, Anthony
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch to merge vcpu.c
>
>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
>> >> > >>
>> >> >
>> >>
>>

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