search for: itir

...pp easily. + * They are handled by sed instead of cpp. + */ + +/* for .S + * itc.i + * itc.d + * + * bsw.0 + * bsw.1 + * + * ssm psr.ic | PSR_DEFAULT_BITS + * ssm psr.ic + * rsm psr.ic + * ssm psr.i + * rsm psr.i + * rsm psr.i | psr.ic + * rsm psr.dt + * ssm psr.dt + * + * mov = cr.ifa + * mov = cr.itir + * mov = cr.isr + * mov = cr.iha + * mov = cr.ipsr + * mov = cr.iim + * mov = cr.iip + * mov = cr.ivr + * mov = psr + * + * mov cr.ifa = + * mov cr.itir = + * mov cr.iha = + * mov cr.ipsr = + * mov cr.ifs = + * mov cr.iip = + * mov cr.kr = + */ + +/* for intrinsics + * ssm psr.i + * rsm psr.i + *...

...pp easily. + * They are handled by sed instead of cpp. + */ + +/* for .S + * itc.i + * itc.d + * + * bsw.0 + * bsw.1 + * + * ssm psr.ic | PSR_DEFAULT_BITS + * ssm psr.ic + * rsm psr.ic + * ssm psr.i + * rsm psr.i + * rsm psr.i | psr.ic + * rsm psr.dt + * ssm psr.dt + * + * mov = cr.ifa + * mov = cr.itir + * mov = cr.isr + * mov = cr.iha + * mov = cr.ipsr + * mov = cr.iim + * mov = cr.iip + * mov = cr.ivr + * mov = psr + * + * mov cr.ifa = + * mov cr.itir = + * mov cr.iha = + * mov cr.ipsr = + * mov cr.ifs = + * mov cr.iip = + * mov cr.kr = + */ + +/* for intrinsics + * ssm psr.i + * rsm psr.i + *...

...to start ski is: > "ski bootloader xen paralinux nomca simscsi=`pwd`/sd" > > Here paralinux is built upon >bk://xen-ia64.bkbits.net/xenlinux-ia64-2.6.11.bk. > > BTW, just saw a small bug in vcpu.c: >IA64FAULT vcpu_itc_d(VCPU *vcpu, UINT64 > ... > if (((itir & ~0xfc) >> 2) < PAGE_SHIFT) { >Should be: > if (((itir & 0xfc) >> 2) < PAGE_SHIFT) { > >Thanks, >Kevin >>-----Original Message----- >>From: xen-ia64-devel-bounces@lists.xensource.com >>[mailto:xen-ia64-devel-bounces@lists.xensource.c...

...ski is: > "ski bootloader xen paralinux nomca simscsi=`pwd`/sd" > > Here paralinux is built upon > bk://xen-ia64.bkbits.net/xenlinux-ia64-2.6.11.bk. > > BTW, just saw a small bug in vcpu.c: > IA64FAULT vcpu_itc_d(VCPU *vcpu, UINT64 > ... > if (((itir & ~0xfc) >> 2) < PAGE_SHIFT) { > Should be: > if (((itir & 0xfc) >> 2) < PAGE_SHIFT) { > > Thanks, > Kevin > >-----Original Message----- > >From: xen-ia64-devel-bounces@lists.xensource.com > >[mailto:xen-ia64-devel-bounces@lists.xen...

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on native

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on native

Hi Xiantao, More comments. Zhang, Xiantao wrote: >>From 696b9eea9f5001a7b7a07c0e58514aa10306b91a Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Fri, 28 Mar 2008 09:51:36 +0800 > Subject: [PATCH] KVM:IA64 : Add head files for kvm/ia64 > > ia64_regs: some defintions for special registers > which aren't defined in

Hi Xiantao, More comments. Zhang, Xiantao wrote: >>From 696b9eea9f5001a7b7a07c0e58514aa10306b91a Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Fri, 28 Mar 2008 09:51:36 +0800 > Subject: [PATCH] KVM:IA64 : Add head files for kvm/ia64 > > ia64_regs: some defintions for special registers > which aren't defined in

This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect call into in-place execution or direct call. The first patch imports helper functions which themselves doesn't interesting things. The second patch replaces the indirect function calls with a

This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect call into in-place execution or direct call. The first patch imports helper functions which themselves doesn't interesting things. The second patch replaces the indirect function calls with a

...long dcr; /* CR0 */ + unsigned long itm; + unsigned long iva; + unsigned long rsv1[5]; + unsigned long pta; /* CR8 */ + unsigned long rsv2[7]; + unsigned long ipsr; /* CR16 */ + unsigned long isr; + unsigned long rsv3; + unsigned long iip; + unsigned long ifa; + unsigned long itir; + unsigned long iipa; + unsigned long ifs; + unsigned long iim; /* CR24 */ + unsigned long iha; + unsigned long rsv4[38]; + unsigned long lid; /* CR64 */ + unsigned long ivr; + unsigned long tpr; + unsigned long eoi; + unsigned long irr[4]; + unsigned long itv; /* CR72 */ +...

...long dcr; /* CR0 */ + unsigned long itm; + unsigned long iva; + unsigned long rsv1[5]; + unsigned long pta; /* CR8 */ + unsigned long rsv2[7]; + unsigned long ipsr; /* CR16 */ + unsigned long isr; + unsigned long rsv3; + unsigned long iip; + unsigned long ifa; + unsigned long itir; + unsigned long iipa; + unsigned long ifs; + unsigned long iim; /* CR24 */ + unsigned long iha; + unsigned long rsv4[38]; + unsigned long lid; /* CR64 */ + unsigned long ivr; + unsigned long tpr; + unsigned long eoi; + unsigned long irr[4]; + unsigned long itv; /* CR72 */ +...

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place