12 messages in com.xensource.lists.xen-ia64-develRE: [Xen-ia64-devel] [PATCH] This is ...
FromSent OnAttachments
Xu, Anthony12 Sep 2005 05:27.patch
Magenheimer, Dan (HP Labs Fort Collins)13 Sep 2005 21:48 
Xu, Anthony14 Sep 2005 18:02 
Magenheimer, Dan (HP Labs Fort Collins)14 Sep 2005 19:08 
Magenheimer, Dan (HP Labs Fort Collins)14 Sep 2005 19:18 
Xu, Anthony14 Sep 2005 19:37 
Magenheimer, Dan (HP Labs Fort Collins)14 Sep 2005 20:52.buildlinux
Xu, Anthony14 Sep 2005 21:47 
Xu, Anthony15 Sep 2005 20:52 
Xu, Anthony16 Sep 2005 04:11 
Magenheimer, Dan (HP Labs Fort Collins)16 Sep 2005 06:03 
Xu, Anthony18 Sep 2005 18:38 
Subject:RE: [Xen-ia64-devel] [PATCH] This is the first patch to merge vcpu.c
From:Magenheimer, Dan (HP Labs Fort Collins) (dan.@hp.com)
Date:09/14/2005 08:52:48 PM
List:com.xensource.lists.xen-ia64-devel
Attachments:
buildlinux - 0.8k

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:anth@intel.com] Sent: Wednesday, September 14, 2005 8:38 PM To: Magenheimer, Dan (HP Labs Fort Collins) Cc: xen-@lists.xensource.com 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.@hp.com]

Sent: 2005年9月15日 10:18 To: Xu, Anthony Cc: xen-@lists.xensource.com 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-@lists.xensource.com [mailto:xen-@lists.xensource.com] On Behalf Of Magenheimer, Dan (HP Labs Fort Collins) Sent: Wednesday, September 14, 2005 8:09 PM To: Xu, Anthony Cc: xen-@lists.xensource.com 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:anth@intel.com] Sent: Wednesday, September 14, 2005 7:03 PM To: Magenheimer, Dan (HP Labs Fort Collins) Cc: xen-@lists.xensource.com 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.@hp.com]

Sent: 2005年9月14日 12:48 To: Xu, Anthony Cc: xen-@lists.xensource.com 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:anth@intel.com] Sent: Monday, September 12, 2005 6:28 AM To: Magenheimer, Dan (HP Labs Fort Collins) Cc: xen-@lists.xensource.com 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 <Anth@intel.com>

Thanks, Anthony