search for: vpsr

...;&regs->ar_fpsr, >+ &isr, &regs->pr, &regs->cr_ifs, regs); >+ return ret.status; >+} >+ >+void reflect_interruption(u64 ifa, u64 isr, u64 iim, >+ u64 vec, REGS *regs) >+{ >+ u64 vector; >+ int status ; >+ VCPU *vcpu = current_vcpu; >+ u64 vpsr = VCPU(vcpu, vpsr); >+ >+ vector = vec2off[vec]; >+ >+ if (!(vpsr & IA64_PSR_IC) && (vector != >IA64_DATA_NESTED_TLB_VECTOR)) { >+ panic_vm(vcpu); >+ return; >+ } >+ >+ switch (vec) { >+ case 32: I want to add a comment of IA64_FP_FAULT_VECTOR. >+...

...;&regs->ar_fpsr, >+ &isr, &regs->pr, &regs->cr_ifs, regs); >+ return ret.status; >+} >+ >+void reflect_interruption(u64 ifa, u64 isr, u64 iim, >+ u64 vec, REGS *regs) >+{ >+ u64 vector; >+ int status ; >+ VCPU *vcpu = current_vcpu; >+ u64 vpsr = VCPU(vcpu, vpsr); >+ >+ vector = vec2off[vec]; >+ >+ if (!(vpsr & IA64_PSR_IC) && (vector != >IA64_DATA_NESTED_TLB_VECTOR)) { >+ panic_vm(vcpu); >+ return; >+ } >+ >+ switch (vec) { >+ case 32: I want to add a comment of IA64_FP_FAULT_VECTOR. >+...

...lob) \ + movl clob = XSI_PSR_IC; \ + ;; \ + st4 [clob] = r0; \ + ;; + +/* pred will be clobbered */ +#define MASK_TO_PEND_OFS (-1) +#define SSM_PSR_I(pred, pred_clob, clob) \ +(pred) movl clob = XSI_PSR_I_ADDR \ + ;; \ +(pred) ld8 clob = [clob] \ + ;; \ + /* if (pred) vpsr.i = 1 */ \ + /* if (pred) (vcpu->vcpu_info->evtchn_upcall_mask)=0 */ \ +(pred) st1 [clob] = r0, MASK_TO_PEND_OFS \ + ;; \ + /* if (vcpu->vcpu_info->evtchn_upcall_pending) */ \ +(pred) ld1 clob = [clob] \ + ;; \ +(pred) cmp.ne.unc pred_clob, p0 = clob, r0 \...

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

...regs (r16-r31) + when bank0 active */ + }; + union { + unsigned long vbgr[16]; + unsigned long bank0_regs[16]; /* bank0 regs (r16-r31) + when bank1 active */ + }; + unsigned long vnat; + unsigned long vbnat; + unsigned long vcpuid[5]; + unsigned long reserved3[11]; + unsigned long vpsr; + unsigned long vpr; + unsigned long reserved4[76]; + union { + unsigned long vcr[128]; + struct { + unsigned 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...

...regs (r16-r31) + when bank0 active */ + }; + union { + unsigned long vbgr[16]; + unsigned long bank0_regs[16]; /* bank0 regs (r16-r31) + when bank1 active */ + }; + unsigned long vnat; + unsigned long vbnat; + unsigned long vcpuid[5]; + unsigned long reserved3[11]; + unsigned long vpsr; + unsigned long vpr; + unsigned long reserved4[76]; + union { + unsigned long vcr[128]; + struct { + unsigned 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...

...ESET, 0); + DEFINE(OFFSET_VECTOR_UND, 4); + DEFINE(OFFSET_VECTOR_SWI, 8); + DEFINE(OFFSET_VECTOR_PABT, 12); + DEFINE(OFFSET_VECTOR_DABT, 16); + DEFINE(OFFSET_VECTOR_IRQ, 24); + DEFINE(OFFSET_VECTOR_FIQ, 28); + BLANK(); + DEFINE(OFFSET_VCPU, offsetof(struct cpu_info, vcpu)); + DEFINE(OFFSET_VPSR, offsetof(struct cpu_info, vspsr)); + DEFINE(OFFSET_VSP, offsetof(struct cpu_info, vsp)); + DEFINE(OFFSET_VLR, offsetof(struct cpu_info, vlr)); + BLANK(); + DEFINE(OFFSET_VCPU_R0, offsetof(struct vcpu_guest_context, r0)); + DEFINE(OFFSET_VCPU_R1, offsetof(struct vcpu_guest_context, r1));...

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions which is necessary to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions which is necessary to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Please review and comments. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Please review and comments. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions

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

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was already merged to linux ia64 test branch. This patch is for linux ia64 test branch. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor.

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was already merged to linux ia64 test branch. This patch is for linux ia64 test branch. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor.

Hi. This patchset is ia64/xen domU patch take 8 which was updated following Tony's review. (Thank you very much, Tony.) This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset is for linux ia64 test branch and depends on some patches for xen common part I'll send separately. To compile, the changesets in x86/xen

Hi. This patchset is ia64/xen domU patch take 8 which was updated following Tony's review. (Thank you very much, Tony.) This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset is for linux ia64 test branch and depends on some patches for xen common part I'll send separately. To compile, the changesets in x86/xen