[Xen-ia64-devel][PATCH]paravirtualize syscall path in file fsys.S
paravirtualize syscall path in file fsys.S --Anthony para_fsys.patch Description: para_fsys.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH] fix a bug about xen_set_kr
fix a bug about xen_set_kr Anthony fix_xen_set_kr_bug.patch Description: fix_xen_set_kr_bug.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Question domU blocking and xen timer interrupt
Hi, Dietmar
As you suggested.
Currently HYPERVISOR_set_timer_op is not used.
for more detail, please see following mail.
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-07/msg00056.ht
ml
Thanks
Atsushi SAKAI
Thanks for your hint.
I tried the PAL_HALT_LIGHT call and the domU gets blocked and woken up when
the time is over or a key is pressed. But I don't see a timer event for this
cr.itm.
I looked at the xen code and saw that your function hlt_timer_fn() was changed
later and the part
if(vcpu_timer_expired(v)){
vcpu_pend_timer(v);
}
was removed. What caused this?
How do I get this timer event?
In the current form - how do I know whether the block was finished by a timer
event or any other event (maybe the key press event)?
Thanks.
Dietmar.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel]PATCH] Remove duplicate check is_running_on_xen
On Mon, 2007-01-15 at 13:33 +0800, Xu, Anthony wrote:
Remove duplicate check is_running_on_xen
Hi Anthony,
I'm not sure I understand why the xen functions, for example
xen_get_psr(), need to support both bare metal and paravirtualized since
the caller always checks for is_running_on_xen. The current code seems
overly paranoid. Would is make more sense to rename these to
__xen_get_psr() and eliminate the running_on_xen check in the assembly?
Then we could still use the native bare metal calls when running a Xen
kernel on bare metal. Am I missing some reason why xen_get_psr() would
ever get called on bare metal? Thanks,
Alex
diff -r 29780963b34f linux-2.6-xen-sparse/arch/ia64/xen/hypercall.S
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypercall.SMon Jan 15
04:27:37 2007 +0800
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypercall.SMon Jan 15
05:02:05 2007 +0800
@@ -11,12 +11,9 @@ GLOBAL_ENTRY(xen_get_psr)
GLOBAL_ENTRY(xen_get_psr)
movl r8=running_on_xen;;
ld4 r8=[r8];;
- cmp.eq p7,p0=r8,r0;;
-(p7) mov r8=psr;;
-(p7) br.ret.sptk.many rp
- ;;
- XEN_HYPER_GET_PSR
- ;;
+ cmp.eq p7,p6=r8,r0;;
+(p7) mov r8=psr
+(p6) XEN_HYPER_GET_PSR
br.ret.sptk.many rp
;;
END(xen_get_psr)
...
linux-2.6-xen-sparse/include/asm-ia64/xen/privop.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/xen/privop.hMon
Jan 15 04:27:37 2007 +0800
+++ b/linux-2.6-xen-sparse/include/asm-ia64/xen/privop.hMon
Jan 15 05:08:12 2007 +0800
@@ -203,24 +203,16 @@ extern void xen_ptcga(unsigned long addr
\
switch(regnum)
{\
case
_IA64_REG_PSR: \
- ia64_intri_res =
(is_running_on_xen()) ?\
- xen_get_psr() : \
- __ia64_getreg(regnum); \
+ ia64_intri_res =
xen_get_psr(); \
break; \
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] fix a bug about xen_set_kr
On Tue, 2007-01-16 at 17:39 +0800, Xu, Anthony wrote: fix a bug about xen_set_kr Hi Anthony, Could you please describe the bug and the fix? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix freeing of privregs structure fordomVTi
On Mon, 2007-01-15 at 21:49 +0900, Masaki Kanno wrote: Hi, I made a patch to modify initialization of VCPU of dom0/domU. Hi Kan, I get softlockups in dom0 (like shown below) with this patch. These occur when running multiple domVTs and shutting them down at the same time. Could you please investigate? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. BUG: soft lockup detected on CPU#0! Modules linked in: Pid: 3179, CPU 0, comm: qemu-dm psr : 1410085a6010 ifs : 8006 ip : [a00100068b02]Not tainted ip is at __hypercall+0x2/0x20 unat: pfs : 8510 rsc : 000b rnat: bsps: pr : 00695a9b ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : b0 : a0010006a3f0 b6 : a0010006a2c0 b7 : f6 : 0 f7 : 0 f8 : 0 f9 : 0 f10 : 0 f11 : 0 r1 : a0010104ec60 r2 : 0030 r3 : f7c2fec8 r8 : r9 : a00100e73228 r10 : r11 : 008ea860 r12 : e004ab95fcb0 r13 : e004ab958000 r14 : r15 : r16 : 008ea840 r17 : 0008ea84 r18 : 0008ea84 r19 : 0001 r20 : 0009804c8a70033f r21 : a00100e75600 r22 : a00201176858 r23 : r24 : 000b r25 : e004ae8a3650 r26 : 8510 r27 : 000b r28 : a00100068b00 r29 : 1412085a6010 r30 : 8006 r31 : 00695a9b Call Trace: [a0010001cfe0] show_stack+0x40/0xa0 sp=e004ab95f910 bsp=e004ab959608 [a0010001d8e0] show_regs+0x840/0x880 sp=e004ab95fae0 bsp=e004ab9595a8 [a001000d7f70] softlockup_tick+0x130/0x160 sp=e004ab95fae0 bsp=e004ab959578 [a001000a1ea0] do_timer+0x9a0/0x9c0 sp=e004ab95fae0 bsp=e004ab959538 [a00100042190] timer_interrupt+0x1f0/0x380 sp=e004ab95fae0 bsp=e004ab9594f8 [a001000d8200] handle_IRQ_event+0x160/0x240 sp=e004ab95fae0 bsp=e004ab9594b8 [a001000d8580] __do_IRQ+0x2a0/0x3c0 sp=e004ab95fae0 bsp=e004ab959470 [a001006a2f60] evtchn_do_upcall+0x1c0/0x320 sp=e004ab95fae0 bsp=e004ab9593d0 [a00100068ea0] xen_event_callback+0x380/0x3c0 sp=e004ab95fae0 bsp=e004ab9593d0 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Implement eager save, lazy restore FP algorithm
On Tue, 2007-01-16 at 12:52 +0800, Xu, Anthony wrote: This patch Implements eager save, lazy restore FP algorithm, This patch reduces the cost of VCPU schedule. Hi Anthony, In theory, this is nice. In practice, I get segfaults doing a kernel build in a domVT with multiple VT domains running. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix freeing of privregs structure fordomVTi
On Tue, 2007-01-16 at 13:58 -0700, Alex Williamson wrote: On Mon, 2007-01-15 at 21:49 +0900, Masaki Kanno wrote: Hi, I made a patch to modify initialization of VCPU of dom0/domU. Hi Kan, I get softlockups in dom0 (like shown below) with this patch. These occur when running multiple domVTs and shutting them down at the same time. Could you please investigate? Thanks, Sorry Kan, after further testing w/o this patch, I can still hit the softlockup occasionally. This patch may not be causing it. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix freeing of privregs structure fordomVTi
On Mon, 2007-01-15 at 21:49 +0900, Masaki Kanno wrote: Hi, I made a patch to modify initialization of VCPU of dom0/domU. Applied. The dom0 softlockup looks like a pre-existing issue in the tree. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Add privilege check back for hypercall
On Tue, 2007-01-16 at 13:33 +0800, Xu, Anthony wrote: Add privilege check back for hypercall Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]paravirtualize syscall path in file fsys.S
On Tue, 2007-01-16 at 17:20 +0800, Xu, Anthony wrote: paravirtualize syscall path in file fsys.S Applied. I split adding fsys.S into the sparse tree as a separate changeset. This makes it much easier to track the changes in the file from the pristine upstream. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel]PATCH] Remove duplicate check is_running_on_xen
Alex Williamson write on 2007年1月17日 11:10: On Wed, 2007-01-17 at 10:17 +0800, Xu, Anthony wrote: There are two duplicate checks as below, so there are two way to eliminate one check. 1. eliminate check in xen_get_tpr, then xen_get_tpr will never be called on bare metal, but it's a little perfomance impact, due to there is another switch inside __ia64_getreg. 2. eliminate check in xen_ia64_getreg, then xen_get_tpr will be called both on para platform or bare metal, it can produce better performance than option 1. so I prefer this. Is the performance difference actually measurable? I suspect it's effectively within the noise of any benchmark. I prefer option 1 because the leaf function when running on bare metal is the same as the native kernel, so we're not duplicating code. Thanks, Okey, I will do this. Anthony Alex ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#13438
Xen/IA64 Healthiness Report All the cases passed in the test. So, only one issue: 1. With serial='pty', UP_VTI booting speed is a little slower. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 13438:43115ffc6635 Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.12.01 MD5: 09a224270416036a8b4e6f8496e97854 Summary Test Report: - Total cases: 16 Passed:16 Failed: 0 Case Name Status Case Description Four_SMPVTI_Coexistpass 4 VTI (mem=256, vcpus=2) Two_UP_VTI_Co pass 2 UP_VTI (mem=256) One_UP_VTIpass1 UP_VTI (mem=256) One_UP_XenU pass1 UP_xenU(mem=256) SMPVTI_LTPpassVTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU pass 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexistpass2 xenU (mem=256, vcpus=2) One_SMPVTI_4096M pass 1 VTI (vcpus=2, mem=4096M) SMPVTI_Network pass 1 VTI (mem=256,vcpu=2) and 'ping' SMPXenU_Networkpass 1 XenU (vcpus=2) and 'ping' One_SMP_XenU pass 1 SMP xenU (vcpus=2) One_SMP_VTIpass 1 SMP VTI (vcpus=2) SMPVTI_Kernel_Build pass VTI (vcpus=4) and do Kernel Build Four_SMPVTI_Coexist pass 4 VTI domains( mem=256, vcpu=2) SMPVTI_Windows pass SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU pass SMPVTI Linux/Windows XenU UPVTI_Kernel_Build pass 1 UP VTI and do kernel build Notes: - The last stable changeset: - 13372:c6b683ba68f5 Thanks, Zhangjingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Add netfornt tx_queue_len
Hi all. When I executed netperf by a short message of UDP, PV domain issued Call trace. I think that GrantEntry was filled with a lot of messages processings. This problem is generated in IA64 only. I corrected to check number of unprocessing queue tx_queue_len before Grant was filled. Is there other a good correction? # ./netperf -t UDP_STREAM -H 10.34.179.101 -l 3 -- -m 10 -M 10 netperf[2474]: bugcheck! 0 [1] Modules linked in: Pid: 2474, CPU 0, comm: netperf psr : 1010081a2010 ifs : 8b9b ip : [a001006c9ce0]Not tainted ip is at network_start_xmit+0xa00/0xe40 unat: pfs : 8b9b rsc : 000b rnat: bsps: pr : 010468241566 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : Best regards, Tomonari Horikoshi tx-queue-len-support.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
