[Xen-ia64-devel] [Patch] massage of elf_sanity_check as x86
Hi,
This small patch output message of elf_sanity_check as x86.
Currently this panic is the only following message.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN)
(XEN)
(XEN) Reboot in five seconds...
(XEN) machine_restart called: spinning
Best Regards,
Akio Takebe
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r de0c04ed4ab7 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cFri Apr 21 10:40:17 2006 -0600
+++ b/xen/arch/ia64/xen/domain.cMon Apr 24 15:05:38 2006 +0900
@@ -751,7 +751,12 @@ unsigned long domain_mpa_to_imva(struct
// see arch/x86/xxx/domain_build.c
int elf_sanity_check(Elf_Ehdr *ehdr)
{
- return (IS_ELF(*ehdr));
+ if (!(IS_ELF(*ehdr)))
+ {
+ printk(DOM0 image is not a Xen-compatible Elf image.\n);
+ return 0;
+ }
+ return 1;
}
static void copy_memory(void *dst, void *src, int size)
msg_of_elf_sanity_check.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: more mmio insn for VTi
Le Lundi 24 Avril 2006 03:55, Xu, Anthony a écrit : One more comment Since we have emulated st8 and st.spill in mmio, Maybe we also need to handle floating register rotation just like in linux kernel. What's your opinion? Sorry, I haven't looked on all these issues. I have to read a little bit more the ASDM before giving you a small valuable answer! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] alt_itlb_miss?
Hi Kevin, Thanks for your explanation. Sorry, I'd like you to explain this once again. Please look at the below figure. 1) Instruction TLB Fault ---+ | +--+ | +--- ENTRY(iltb_miss) /* Check ifa (It was VHPT_CCHAIN_LOOKUP before here) */ mov r16 = cr.ifa extr.u r17=r16,59,5 cmp.eq p6,p0=0x1e,r17 (p6) br.cond.spnt late_alt_itlb_miss -+ cmp.eq p6,p0=0x1d,r17| (p6) br.cond.spnt late_alt_itlb_miss ---+ | | | | | 2) Alternate Instruction TLB Fault ---+| | || | ++| | | | | +--- ENTRY(alt_itlb_miss)| | mov r16=cr.ifa | | | | late_alt_itlb_miss: ---+-+ /* Check cpl */ cmp.ne p8,p0=r0,r23 or r19=r17,r19 or r19=r19,r18 (p8) br.cond.spnt page_fault + /* Check ifa with my patch */ + extr.u r22=r16,59,5 + cmp.ne p8,p0=0x1e,r22 +(p8) br.cond.spnt 1f --+ | itc.i r19 | mov pr=r31,-1 | rfi | | +1: ---+ + FORCE_CRASH If case 1), I think that a FORCE_CRASH and ifa checking is unnecessary according to your explanation. If case 2), I think that a FORCE_CRASH and ifa checking is necessary. Because, I thought that Xen may use a wrong address. If case 2), does Xen trust only cpl? Best regards, Kan Tian, Kevin wrote: From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2006定4埖21晩 18:56 Hi Kan, Thanks, this looks like exactly what we need. If there are no other comments, please send me this patch w/ a Signed-off-by and we can get it in tree. BTW, glad to hear you're working on the FPSWA issue and are making good progress! Thanks, Alex Seems OK. One small comment is that we may also remove FORCE_CRASH completely since the assumption to add that check doesn't exist now. Actually VHPT_CCHAIN_LOOKUP already makes check upon VMM area to decide whether jumping to alt_itlb_miss handler. In this case, simply removing FORCE_CRASH line can also work. :-) If alt_itlb_fault occurred, we need ifa checking and FORCE_CRASH, don't we? Therefore I don't need to change my patch, do I? The check is already made before jumping to alt_itlb_miss. Also architecturally there's no limitation to prevent uncacheable instruction falling into that category. So I think there's no need for existence of FORCE_CRASH there, right? :-) Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] PATCH: more mmio insn for VTi
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006?4?24? 15:42 To: Xu, Anthony; xen-ia64-devel@lists.xensource.com; Magenheimer, Dan (HP Labs Fort Collins); Alex Williamson Subject: Re: [Xen-ia64-devel] PATCH: more mmio insn for VTi Le Lundi 24 Avril 2006 03:55, Xu, Anthony a écrit : One more comment Since we have emulated st8 and st.spill in mmio, Maybe we also need to handle floating register rotation just like in linux kernel. What's your opinion? Sorry, I haven't looked on all these issues. I have to read a little bit more the ASDM before giving you a small valuable answer! Ok, I can do this, and then you can give your suggestions. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] alt_itlb_miss?
Hi, Kan, Thanks for detail figure. From architecture correctness, I think your patch is yes required though case 2 is only walked before dom0 loads rr7 (After that, vhpt table will be enabled from then on and case 1 is the only path then). So please re-submit the patch again and it's better if you could move the check to the point before late_alt_itlb_miss to avoid duplicated check in case 2. Also, it's better to jump to page_fault instead of crash the whole xen here which is over-killed. :-) Thanks, Kevin -Original Message- From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2006年4月24日 15:40 To: Tian, Kevin Cc: Alex Williamson; Isaku Yamahata; xen-ia64-devel Subject: Re: [Xen-ia64-devel] alt_itlb_miss? Hi Kevin, Thanks for your explanation. Sorry, I'd like you to explain this once again. Please look at the below figure. 1) Instruction TLB Fault ---+ | +--+ | +--- ENTRY(iltb_miss) /* Check ifa (It was VHPT_CCHAIN_LOOKUP before here) */ mov r16 = cr.ifa extr.u r17=r16,59,5 cmp.eq p6,p0=0x1e,r17 (p6) br.cond.spnt late_alt_itlb_miss -+ cmp.eq p6,p0=0x1d,r17| (p6) br.cond.spnt late_alt_itlb_miss ---+ | | | | | 2) Alternate Instruction TLB Fault ---+| | || | ++| | | | | +--- ENTRY(alt_itlb_miss)| | mov r16=cr.ifa | | | | late_alt_itlb_miss: ---+-+ /* Check cpl */ cmp.ne p8,p0=r0,r23 or r19=r17,r19 or r19=r19,r18 (p8) br.cond.spnt page_fault + /* Check ifa with my patch */ + extr.u r22=r16,59,5 + cmp.ne p8,p0=0x1e,r22 +(p8) br.cond.spnt 1f --+ | itc.i r19 | mov pr=r31,-1 | rfi | | +1: ---+ + FORCE_CRASH If case 1), I think that a FORCE_CRASH and ifa checking is unnecessary according to your explanation. If case 2), I think that a FORCE_CRASH and ifa checking is necessary. Because, I thought that Xen may use a wrong address. If case 2), does Xen trust only cpl? Best regards, Kan Tian, Kevin wrote: From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2006定4��21�� 18:56 Hi Kan, Thanks, this looks like exactly what we need. If there are no other comments, please send me this patch w/ a Signed-off-by and we can get it in tree. BTW, glad to hear you're working on the FPSWA issue and are making good progress! Thanks, Alex Seems OK. One small comment is that we may also remove FORCE_CRASH completely since the assumption to add that check doesn't exist now. Actually VHPT_CCHAIN_LOOKUP already makes check upon VMM area to decide whether jumping to alt_itlb_miss handler. In this case, simply removing FORCE_CRASH line can also work. :-) If alt_itlb_fault occurred, we need ifa checking and FORCE_CRASH, don't we? Therefore I don't need to change my patch, do I? The check is already made before jumping to alt_itlb_miss. Also architecturally there's no limitation to prevent uncacheable instruction falling into that category. So I think there's no need for existence of FORCE_CRASH there, right? :-) Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: [resent] cleanup + fph handling
Hi,
this patch moves switch_to macro from xensystem.h and put its body directly in
context_switch. FP saved and restore is slighly optimized: fph is *still*
enabled and not anymore disabled.
Misc cleanup.
Note: not enabling fph before saving fph in context switch does not work. I
will look on this issue. However, I think it is worth adding this patch.
Tested by boot+halt of dom0+domU.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 80dca45d10905f8513e4bd2c77a7642833308db3
# Parent de0c04ed4ab7b9c4572c42df2de838e2b243a8e2
Move contents of switch_to macro from xensystem.h to context_switch function.
Let fph enabled after context switch.
Cleanup (unused function/variables, debug printf...)
vmx_ia64_switch_to removed (was unused).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r de0c04ed4ab7 -r 80dca45d1090 xen/arch/ia64/linux-xen/setup.c
--- a/xen/arch/ia64/linux-xen/setup.c Fri Apr 21 16:40:17 2006
+++ b/xen/arch/ia64/linux-xen/setup.c Mon Apr 24 04:04:00 2006
@@ -384,7 +384,9 @@
{
unw_init();
+#ifndef XEN
ia64_patch_vtop((u64) __start___vtop_patchlist, (u64) __end___vtop_patchlist);
+#endif
*cmdline_p = __va(ia64_boot_param-command_line);
#ifndef XEN
@@ -931,9 +933,11 @@
#endif
}
+#ifndef XEN
void
check_bugs (void)
{
ia64_patch_mckinley_e9((unsigned long) __start___mckinley_e9_bundles,
(unsigned long) __end___mckinley_e9_bundles);
}
+#endif
diff -r de0c04ed4ab7 -r 80dca45d1090 xen/arch/ia64/vmx/vmx_entry.S
--- a/xen/arch/ia64/vmx/vmx_entry.S Fri Apr 21 16:40:17 2006
+++ b/xen/arch/ia64/vmx/vmx_entry.S Mon Apr 24 04:04:00 2006
@@ -36,48 +36,6 @@
#include asm/vhpt.h
#include asm/vmmu.h
#include vmx_minstate.h
-
-/*
- * prev_task - vmx_ia64_switch_to(struct task_struct *next)
- * With Ingo's new scheduler, interrupts are disabled when this routine gets
- * called. The code starting at .map relies on this. The rest of the code
- * doesn't care about the interrupt masking status.
- *
- * Since we allocate domain stack in xenheap, there's no need to map new
- * domain's stack since all xenheap is mapped by TR. Another different task
- * for vmx_ia64_switch_to is to switch to bank0 and change current pointer.
- */
-GLOBAL_ENTRY(vmx_ia64_switch_to)
- .prologue
- alloc r16=ar.pfs,1,0,0,0
- DO_SAVE_SWITCH_STACK
- .body
-
- bsw.0 // Switch to bank0, because bank0 r21 is current pointer
- ;;
- adds r22=IA64_TASK_THREAD_KSP_OFFSET,r13
- movl r25=init_task
- adds r26=IA64_TASK_THREAD_KSP_OFFSET,in0
- ;;
- st8 [r22]=sp // save kernel stack pointer of old task
- ;;
- /*
- * TR always mapped this task's page, we can skip doing it again.
- */
- ld8 sp=[r26] // load kernel stack pointer of new task
- mov r21=in0 // update current application register
- mov r8=r13 // return pointer to previously running task
- mov r13=in0 // set current pointer
- ;;
- bsw.1
- ;;
- DO_LOAD_SWITCH_STACK
-
-#ifdef CONFIG_SMP
- sync.i// ensure fcs done by this CPU are visible on other CPUs
-#endif
- br.ret.sptk.many rp // boogie on out in new context
-END(vmx_ia64_switch_to)
GLOBAL_ENTRY(ia64_leave_nested)
rsm psr.i
diff -r de0c04ed4ab7 -r 80dca45d1090 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Fri Apr 21 16:40:17 2006
+++ b/xen/arch/ia64/xen/domain.c Mon Apr 24 04:04:00 2006
@@ -70,11 +70,8 @@
#define IS_XEN_ADDRESS(d,a) ((a = d-xen_vastart) (a = d-xen_vaend))
/* FIXME: where these declarations should be there ? */
-extern void domain_pend_keyboard_interrupt(int);
extern long platform_is_hp_ski(void);
-extern void sync_split_caches(void);
extern void serial_input_init(void);
-
static void init_switch_stack(struct vcpu *v);
void build_physmap_table(struct domain *d);
@@ -302,7 +299,6 @@
{
struct pt_regs *regs = vcpu_regs (v);
- printf(arch_getdomaininfo_ctxt\n);
c-regs = *regs;
c-vcpu.evtchn_vector = v-vcpu_info-arch.evtchn_vector;
@@ -314,7 +310,6 @@
struct pt_regs *regs = vcpu_regs (v);
struct domain *d = v-domain;
- printf(arch_set_info_guest\n);
if ( test_bit(_VCPUF_initialised, v-vcpu_flags) )
return 0;
if (c-flags VGCF_VMX_GUEST) {
@@ -866,9 +861,8 @@
dom0_start = alloc_boot_pages(dom0_size PAGE_SHIFT, dom0_align PAGE_SHIFT);
dom0_start = PAGE_SHIFT;
if (!dom0_start) {
- printf(alloc_dom0: can't allocate contiguous memory size=%lu\n,
+ panic(alloc_dom0: can't allocate contiguous memory size=%lu\n,
dom0_size);
- while(1);
}
printf(alloc_dom0: dom0_start=0x%lx\n, dom0_start);
#else
@@ -1133,17 +1127,6 @@
while(1);
}
-
-#if 0
-void switch_to(struct vcpu *prev, struct vcpu *next)
-{
- struct vcpu *last;
-
- __switch_to(prev,next,last);
- //set_current(next);
-}
-#endif
-
void domain_pend_keyboard_interrupt(int irq)
{
vcpu_pend_interrupt(dom0-vcpu[0],irq);
@@ -1154,10 +1137,6 @@
ia64_save_fpu(v-arch._thread.fph);
if (VMX_DOMAIN(v))
vmx_save_state(v);
- else {
- if (IA64_HAS_EXTRA_STATE(v))
- ia64_save_extra(v);
- }
// FIXME SMP: Anything else
Re: [Xen-ia64-devel] alt_itlb_miss?
Le Lundi 24 Avril 2006 10:30, Tian, Kevin a écrit : From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月24日 16:24 Le Lundi 24 Avril 2006 09:52, Tian, Kevin a écrit : Hi, Kan, Thanks for detail figure. From architecture correctness, I think your patch is yes required though case 2 is only walked before dom0 loads rr7 (After that, vhpt table will be enabled from then on and case 1 is the only path then). Is VHPT enabled for rr7 ? It really depends on where you look. eg in vhpt.h: #define VHPT_ENABLED 1 #define VHPT_ENABLED_REGION_0_TO_6 1 #define VHPT_ENABLED_REGION_7 0 There are cleanup to do... Above definition is stale and never used nowadays which does need cleanup. See set_one_rr where rr7 will be set with vhpt table enabled absolutely at the first time when guest tries to mov_to_rr. Yes. Even VHPT_ENABLED itself is questionable. Does anybody ever expect to run a xen/ia64 without vhpt table? I don't think so... Well it may be useful for debugging, but I really doubt it works! So I will do cleanup if nobody disagree. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] PATCH: [resent] cleanup + fph handling
From: Tristan Gingold Sent: 2006年4月24日 16:40 Hi, this patch moves switch_to macro from xensystem.h and put its body directly in context_switch. FP saved and restore is slighly optimized: fph is *still* enabled and not anymore disabled. Misc cleanup. Note: not enabling fph before saving fph in context switch does not work. I will look on this issue. However, I think it is worth adding this patch. If you failed at the first context switch, the possible cause is in head.S where psr.dfh is initialized as disabled for idle domain. Then the first time when you switch from idle to domain0, disabled fp fault occurs unless you explicitly enable psr.dfh like in your patch. This is one place where psr value doesn't get from hardware exception. Linux is immune because it always touches fph only for the one owning the that high area. Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: [resent] cleanup + fph handling
Le Lundi 24 Avril 2006 11:51, Tristan Gingold a écrit : Le Lundi 24 Avril 2006 11:06, Tian, Kevin a écrit : From: Tristan Gingold Sent: 2006年4月24日 16:40 Hi, this patch moves switch_to macro from xensystem.h and put its body directly in context_switch. FP saved and restore is slighly optimized: fph is *still* enabled and not anymore disabled. Misc cleanup. Note: not enabling fph before saving fph in context switch does not work. I will look on this issue. However, I think it is worth adding this patch. If you failed at the first context switch, the possible cause is in head.S where psr.dfh is initialized as disabled for idle domain. Then the first time when you switch from idle to domain0, disabled fp fault occurs unless you explicitly enable psr.dfh like in your patch. This is one place where psr value doesn't get from hardware exception. Oops, this may be correct for all the AP cpus! This now works. Thank you Kevin, you were on the right way! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH [resent**2]: FPH handling and cleanup
Hi,
thank you for all the comments. This patch improve context switch time (by a
few ns). FPH is always enabled in Xen.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID f9ffc95fbd428c006b3ecae297ab98278ae1351a
# Parent de0c04ed4ab7b9c4572c42df2de838e2b243a8e2
Move contents of switch_to macro from xensystem.h to context_switch function.
Initialize FPU on all processors. FPH is always enabled in Xen.
Speed up context-switch (a little bit) by not enabling/disabling FPH.
Cleanup (unused function/variables, debug printf...)
vmx_ia64_switch_to removed (was unused).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r de0c04ed4ab7 -r f9ffc95fbd42 xen/arch/ia64/linux-xen/setup.c
--- a/xen/arch/ia64/linux-xen/setup.c Fri Apr 21 16:40:17 2006
+++ b/xen/arch/ia64/linux-xen/setup.c Mon Apr 24 05:55:06 2006
@@ -384,7 +384,9 @@
{
unw_init();
+#ifndef XEN
ia64_patch_vtop((u64) __start___vtop_patchlist, (u64) __end___vtop_patchlist);
+#endif
*cmdline_p = __va(ia64_boot_param-command_line);
#ifndef XEN
@@ -870,6 +872,11 @@
#endif
BUG();
+#ifdef XEN
+ ia64_fph_enable();
+ __ia64_init_fpu();
+#endif
+
ia64_mmu_init(ia64_imva(cpu_data));
ia64_mca_cpu_init(ia64_imva(cpu_data));
@@ -931,9 +938,11 @@
#endif
}
+#ifndef XEN
void
check_bugs (void)
{
ia64_patch_mckinley_e9((unsigned long) __start___mckinley_e9_bundles,
(unsigned long) __end___mckinley_e9_bundles);
}
+#endif
diff -r de0c04ed4ab7 -r f9ffc95fbd42 xen/arch/ia64/vmx/vmx_entry.S
--- a/xen/arch/ia64/vmx/vmx_entry.S Fri Apr 21 16:40:17 2006
+++ b/xen/arch/ia64/vmx/vmx_entry.S Mon Apr 24 05:55:06 2006
@@ -36,48 +36,6 @@
#include asm/vhpt.h
#include asm/vmmu.h
#include vmx_minstate.h
-
-/*
- * prev_task - vmx_ia64_switch_to(struct task_struct *next)
- * With Ingo's new scheduler, interrupts are disabled when this routine gets
- * called. The code starting at .map relies on this. The rest of the code
- * doesn't care about the interrupt masking status.
- *
- * Since we allocate domain stack in xenheap, there's no need to map new
- * domain's stack since all xenheap is mapped by TR. Another different task
- * for vmx_ia64_switch_to is to switch to bank0 and change current pointer.
- */
-GLOBAL_ENTRY(vmx_ia64_switch_to)
- .prologue
- alloc r16=ar.pfs,1,0,0,0
- DO_SAVE_SWITCH_STACK
- .body
-
- bsw.0 // Switch to bank0, because bank0 r21 is current pointer
- ;;
- adds r22=IA64_TASK_THREAD_KSP_OFFSET,r13
- movl r25=init_task
- adds r26=IA64_TASK_THREAD_KSP_OFFSET,in0
- ;;
- st8 [r22]=sp // save kernel stack pointer of old task
- ;;
- /*
- * TR always mapped this task's page, we can skip doing it again.
- */
- ld8 sp=[r26] // load kernel stack pointer of new task
- mov r21=in0 // update current application register
- mov r8=r13 // return pointer to previously running task
- mov r13=in0 // set current pointer
- ;;
- bsw.1
- ;;
- DO_LOAD_SWITCH_STACK
-
-#ifdef CONFIG_SMP
- sync.i// ensure fcs done by this CPU are visible on other CPUs
-#endif
- br.ret.sptk.many rp // boogie on out in new context
-END(vmx_ia64_switch_to)
GLOBAL_ENTRY(ia64_leave_nested)
rsm psr.i
diff -r de0c04ed4ab7 -r f9ffc95fbd42 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Fri Apr 21 16:40:17 2006
+++ b/xen/arch/ia64/xen/domain.c Mon Apr 24 05:55:06 2006
@@ -70,11 +70,8 @@
#define IS_XEN_ADDRESS(d,a) ((a = d-xen_vastart) (a = d-xen_vaend))
/* FIXME: where these declarations should be there ? */
-extern void domain_pend_keyboard_interrupt(int);
extern long platform_is_hp_ski(void);
-extern void sync_split_caches(void);
extern void serial_input_init(void);
-
static void init_switch_stack(struct vcpu *v);
void build_physmap_table(struct domain *d);
@@ -302,7 +299,6 @@
{
struct pt_regs *regs = vcpu_regs (v);
- printf(arch_getdomaininfo_ctxt\n);
c-regs = *regs;
c-vcpu.evtchn_vector = v-vcpu_info-arch.evtchn_vector;
@@ -314,7 +310,6 @@
struct pt_regs *regs = vcpu_regs (v);
struct domain *d = v-domain;
- printf(arch_set_info_guest\n);
if ( test_bit(_VCPUF_initialised, v-vcpu_flags) )
return 0;
if (c-flags VGCF_VMX_GUEST) {
@@ -866,9 +861,8 @@
dom0_start = alloc_boot_pages(dom0_size PAGE_SHIFT, dom0_align PAGE_SHIFT);
dom0_start = PAGE_SHIFT;
if (!dom0_start) {
- printf(alloc_dom0: can't allocate contiguous memory size=%lu\n,
+ panic(alloc_dom0: can't allocate contiguous memory size=%lu\n,
dom0_size);
- while(1);
}
printf(alloc_dom0: dom0_start=0x%lx\n, dom0_start);
#else
@@ -1133,17 +1127,6 @@
while(1);
}
-
-#if 0
-void switch_to(struct vcpu *prev, struct vcpu *next)
-{
- struct vcpu *last;
-
- __switch_to(prev,next,last);
- //set_current(next);
-}
-#endif
-
void domain_pend_keyboard_interrupt(int irq)
{
vcpu_pend_interrupt(dom0-vcpu[0],irq);
@@ -1154,10 +1137,6 @@
ia64_save_fpu(v-arch._thread.fph);
if (VMX_DOMAIN(v))
vmx_save_state(v);
- else {
- if (IA64_HAS_EXTRA_STATE(v))
- ia64_save_extra(v);
- }
// FIXME SMP: Anything
[Xen-ia64-devel] [PATCH] Remove FORCE_CRASH from alt_itlb_miss
Hi, This patch removed FORCE_CRASH from alt_itlb_miss handler. Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan remove_FORCE_CRASH.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] PATCH: [resent] cleanup + fph handling
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月24日 18:03 Le Lundi 24 Avril 2006 11:51, Tristan Gingold a écrit : Le Lundi 24 Avril 2006 11:06, Tian, Kevin a écrit : From: Tristan Gingold Sent: 2006年4月24日 16:40 Hi, this patch moves switch_to macro from xensystem.h and put its body directly in context_switch. FP saved and restore is slighly optimized: fph is *still* enabled and not anymore disabled. Misc cleanup. Note: not enabling fph before saving fph in context switch does not work. I will look on this issue. However, I think it is worth adding this patch. If you failed at the first context switch, the possible cause is in head.S where psr.dfh is initialized as disabled for idle domain. Then the first time when you switch from idle to domain0, disabled fp fault occurs unless you explicitly enable psr.dfh like in your patch. This is one place where psr value doesn't get from hardware exception. Oops, this may be correct for all the AP cpus! This now works. Thank you Kevin, you were on the right way! Tristan. Nice to know it working now. Actually I didn't realize it as an AP-only issue and you gave it a final shoot. :-) Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
the P2M/VP patch merge plan (was Re: [Xen-ia64-devel] [PATCH][RFC][TAKE5] the P2M/VP patches)
Hello. For those who are curious about the P2M/VP patch merge. I finished tedious patch clean up and attached the patches for those who want to review. My plan is that the merge will be done at the 5 steps as follows. I plan to send the next patches once the previous step patches are accepted. (step0 and step1 will be posted simultaneously) From tomorrow I begin to post the patches. thanks. # step 0 # arch independent/x86 depedent patch 9762:d44143d4479c_pci-dma-xen-common.patch # arch-independent 9763:992f8619517e_xen_arch_privcmd_mmap.patch # arch-independent # step 1 # dom0 vp model xen part 9764:e277622cc942_rules_mk.patch 9765:290b8d621c03_assign_lookup_xen.patch 9766:66dac877aa42_efi_memmap_walk_type_xen.patch 9767:796aadb735e0_dom0_construct_xen.patch 9768:9636abaa6959_dom0vp_hypercall_xen.patch # dom0 vp model linux part 9769:15b27098a447_Kconfig.patch 9770:29386e897821_dom0vp_hypercall_linux.patch 9771:ed0baafd91fb_dma_paravirtualization_linux.patch 9772:a1cb7dec2862_arch_ia64_xen_makefile_linux.patch 9773:b0425f9e8c13_lib_makefile_linux.patch # arch-independent # step 2 # grant_table_xen_part 9774:c1f254bbe947_grant_table_xen.patch 9775:744d275ab2bc_xen_common_memory_c_work_around_xen.patch # grant_table_linux_part 9776:3d1ae2337e12_xenia64_init_linux.patch 9777:2ff3326598a5_grant_table_hypercall_work_around.patch 9778:8606d07e1518_arch_free_page_linux.patch 9779:b2e539212858_blkback_linux.patch # arch-independent 9780:ffd79e3ceeda_privcmd_direct_remap_pfn_range_linux.patch 9781:b81d3485ef53_xen_util_linux.patch # xenmem_decrease_reservation_work_around 9782:6966d83b14f7_xenmem_reservation_op_work_around_linux.patch 9783:81212b0e3fde_xenmem_balloon_driver_linux.patch # step 3 # ia64_netback_netfront_linux_part 9784:173035a696c9_linux_defconfig_xen0_ia64.patch 9785:db03500ac0c7_linux_defconfig_xenU_ia64.patch 9786:c53b1dfa7a96_linux_defconfig_xen_ia64.patch 9787:20e7e9148c39_arch_ia64_kconfig_linux.patch 9788:c697fd0953fa.patch 9789:9992a3ca79f7_arch_ia64_xen_drivers_makefile_linux.patch 9790:ff10626ed0d4_arch_ia64_xen_drivers_core_makefile_linux.patch 9791:8427a6d59ce1_netback_linux.patch # arch-independent 9792:acd9e93e3c53.patch 9793:5155113319f1_netback_netfront_hypervisor_to_compile_linux.patch # step 4 # balloon_driver_xen_part 9794:39f606de_balloon_driver_xen.patch 9795:6821b5f25e12_remove_dom0vp_populate_physmap_xen.patch 9796:c267d19b97ab_balloon_driver_linux.patch 9797:98ac81068cf5_remove_populate_physmap_linux.patch # step 5 # work around 9805:78c8fad0944a_balloon_c_work_around_linux.patch 9806:f2e025463bb8_make_vhpt_64kb_work_around.patch -- yamahata p2m_vp_patches_take_merge.tar.bz2 Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH [resent**2]: FPH handling and cleanup
Alex, please do not integrate xen-system4.diffs. After much testing, there is at least one path where saving fp registers faults (I got it with a 12 VCPUs domain). I have to look more. Please, integrate xen-system3.diffs (the previous one), it is much more safer. Excuse me for not testing enough. I am sorry. Tristan. Le Lundi 24 Avril 2006 13:20, Tristan Gingold a écrit : Hi, thank you for all the comments. This patch improve context switch time (by a few ns). FPH is always enabled in Xen. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel] [PATCH][RFC][TAKE5] the P2M/VP patches)
Hi, just a question: is P2M/VP SMP-h/g safe ? Please do the merge even if not yet SMP ready. I will work to re-enable SMP. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] SetVirtualAddressMap emulation support
Hi, I'm working on FPSWA support, and I'm thinking that I will offer a dummy fpswa function to dom0/domU. Therefore I think that Xen has to support the SetVirtualAddressMap() emulation of EFI. This patch supports the SetVirtualAddressMap() emulation in Xen. I confirmed that following EFI Runtime emulation worked in a virtual address. - GetTime() in dom0 - GetTime() in domU Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan efi_set_virt_addr_map.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] SetVirtualAddressMap emulation support
Le Lundi 24 Avril 2006 16:45, Masaki Kanno a écrit : Hi, I'm working on FPSWA support, and I'm thinking that I will offer a dummy fpswa function to dom0/domU. Therefore I think that Xen has to support the SetVirtualAddressMap() emulation of EFI. This patch supports the SetVirtualAddressMap() emulation in Xen. I confirmed that following EFI Runtime emulation worked in a virtual address. - GetTime() in dom0 - GetTime() in domU Hi, Three points: * you should write a generic function to do vcpu_tpa+__va(translate_domain_mpaddr). * I prefer '|' MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB|EFI_MEMORY_RUNTIME,HYPERCALL_START,HYPERCALL_END,1); instead of '+' MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB+EFI_MEMORY_RUNTIME,HYPERCALL_START,HYPERCALL_END,1); * You don't handle vcpu_tpa failure. This may never happen for GetTime, but fore sure may happen for other calls. This may be not trivial. Thank you. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RFC: which version of as/gas are you using?
Hi, In order to remove some warnings from as, we need to enable the .serialize directive. Unfortunatly this directive is not available in old verion of gas (before 1.15 ?). RHEL4 gas supports it. If we want to use the directive, everybody should either use a recent enough distribution or a recent enough gas. [I don't want to autotest or use configure]. Here is the patch if you want to test. Comments are welcome. Tristan. diff -r f9ffc95fbd42 xen/arch/ia64/xen/hyperprivop.S --- a/xen/arch/ia64/xen/hyperprivop.S Mon Apr 24 05:55:06 2006 +++ b/xen/arch/ia64/xen/hyperprivop.S Mon Apr 24 13:06:10 2006 @@ -2076,7 +2076,6 @@ (p6) itc.d r22;; (p7) itc.i r22;; dv_serialize_data - // FIXME: how do I make assembler warnings go away here? // vhpt_insert(r23=vaddr,r22=pte,r24=logps2) thash r28=r23 or r26=1,r22;; diff -r f9ffc95fbd42 xen/include/asm-ia64/config.h --- a/xen/include/asm-ia64/config.h Mon Apr 24 05:55:06 2006 +++ b/xen/include/asm-ia64/config.h Mon Apr 24 13:06:10 2006 @@ -283,4 +283,8 @@ #define FORCE_CRASHbreak.m 0;; #endif +/* Allow .serialize.data/instruction in asm files. + Old as doesn't handle this. */ +#define HAVE_SERIALIZE_DIRECTIVE + #endif /* _IA64_CONFIG_H_ */ diff -r f9ffc95fbd42 xen/arch/ia64/xen/hyperprivop.S --- a/xen/arch/ia64/xen/hyperprivop.S Mon Apr 24 05:55:06 2006 +++ b/xen/arch/ia64/xen/hyperprivop.S Mon Apr 24 13:06:10 2006 @@ -2076,7 +2076,6 @@ (p6) itc.d r22;; (p7) itc.i r22;; dv_serialize_data - // FIXME: how do I make assembler warnings go away here? // vhpt_insert(r23=vaddr,r22=pte,r24=logps2) thash r28=r23 or r26=1,r22;; diff -r f9ffc95fbd42 xen/include/asm-ia64/config.h --- a/xen/include/asm-ia64/config.h Mon Apr 24 05:55:06 2006 +++ b/xen/include/asm-ia64/config.h Mon Apr 24 13:06:10 2006 @@ -283,4 +283,8 @@ #define FORCE_CRASH break.m 0;; #endif +/* Allow .serialize.data/instruction in asm files. + Old as doesn't handle this. */ +#define HAVE_SERIALIZE_DIRECTIVE + #endif /* _IA64_CONFIG_H_ */ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] rx2600 boot failure since 9739
Update: Boot is successful with mem=1024M on the xen cmdline. It only fails when Xen is allowed to see all 4G Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 3/9] [P2M/VP step 1] xen: introduce efi_memmap_walk_type
3 / 9
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 66dac877aa4264c42188a3cee6176cef940fd344
# Parent 290b8d621c031a9fa2c72a60f4ce37dfc6029191
introduce efi_memmap_walk_type() for the next dom0 builder patch.
PATCHNAME: efi_memmap_walk_type_xen
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 290b8d621c03 -r 66dac877aa42 xen/arch/ia64/linux-xen/efi.c
--- a/xen/arch/ia64/linux-xen/efi.c Mon Apr 24 22:27:59 2006 +0900
+++ b/xen/arch/ia64/linux-xen/efi.c Mon Apr 24 22:28:00 2006 +0900
@@ -455,6 +455,27 @@ efi_memmap_walk_uc (efi_freemem_callback
}
}
+#ifdef XEN
+void
+efi_memmap_walk_type(u32 type, efi_walk_type_callback_t callback, void *arg)
+{
+ void *efi_map_start, *efi_map_end, *p;
+ efi_memory_desc_t *md;
+ u64 efi_desc_size;
+
+ efi_map_start = __va(ia64_boot_param-efi_memmap);
+ efi_map_end = efi_map_start + ia64_boot_param-efi_memmap_size;
+ efi_desc_size = ia64_boot_param-efi_memdesc_size;
+
+ for (p = efi_map_start; p efi_map_end; p += efi_desc_size) {
+ md = p;
+ if (md-type == type) {
+ if ((*callback)(md, arg) 0)
+ return;
+ }
+ }
+}
+#endif
/*
* Look for the PAL_CODE region reported by EFI and maps it using an
diff -r 290b8d621c03 -r 66dac877aa42 xen/include/asm-ia64/linux-xen/linux/efi.h
--- a/xen/include/asm-ia64/linux-xen/linux/efi.hMon Apr 24 22:27:59
2006 +0900
+++ b/xen/include/asm-ia64/linux-xen/linux/efi.hMon Apr 24 22:28:00
2006 +0900
@@ -293,6 +293,10 @@ extern void efi_map_pal_code (void);
extern void efi_map_pal_code (void);
extern void efi_map_memmap(void);
extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
+#ifdef XEN
+typedef int (*efi_walk_type_callback_t)(efi_memory_desc_t *md, void *arg);
+extern void efi_memmap_walk_type(u32 type, efi_walk_type_callback_t callback,
void *arg);
+#endif
extern void efi_gettimeofday (struct timespec *ts);
extern void efi_enter_virtual_mode (void); /* switch EFI to virtual mode,
if possible */
extern u64 efi_get_iobase (void);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 2/9] [P2M/VP step 1] xen: introduce P2M conversion
2 / 9
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 290b8d621c031a9fa2c72a60f4ce37dfc6029191
# Parent e277622cc9429abcc3b9c33479ed3784ba909c87
introduce P2M conversion functions necessary for dom0vp model.
PATCHNAME: assign_lookup_xen
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r e277622cc942 -r 290b8d621c03 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cMon Apr 24 22:27:57 2006 +0900
+++ b/xen/arch/ia64/xen/domain.cMon Apr 24 22:27:59 2006 +0900
@@ -54,7 +54,9 @@
#include asm/regionreg.h
#include asm/dom_fw.h
+#ifndef CONFIG_XEN_IA64_DOM0_VP
#define CONFIG_DOMAIN0_CONTIGUOUS
+#endif
unsigned long dom0_start = -1L;
unsigned long dom0_size = 512*1024*1024;
unsigned long dom0_align = 64*1024*1024;
@@ -503,98 +505,290 @@ void new_thread(struct vcpu *v,
}
}
+static pte_t*
+lookup_alloc_domain_pte(struct domain* d, unsigned long mpaddr)
+{
+struct page_info *pt;
+struct mm_struct *mm = d-arch.mm;
+pgd_t *pgd;
+pud_t *pud;
+pmd_t *pmd;
+
+BUG_ON(mm-pgd == NULL);
+pgd = pgd_offset(mm, mpaddr);
+if (pgd_none(*pgd)) {
+pgd_populate(mm, pgd, pud_alloc_one(mm,mpaddr));
+pt = maddr_to_page(pgd_val(*pgd));
+list_add_tail(pt-list, d-arch.mm-pt_list);
+}
+
+pud = pud_offset(pgd, mpaddr);
+if (pud_none(*pud)) {
+pud_populate(mm, pud, pmd_alloc_one(mm,mpaddr));
+pt = maddr_to_page(pud_val(*pud));
+list_add_tail(pt-list, d-arch.mm-pt_list);
+}
+
+pmd = pmd_offset(pud, mpaddr);
+if (pmd_none(*pmd)) {
+pmd_populate_kernel(mm, pmd, pte_alloc_one_kernel(mm, mpaddr));
+pt = maddr_to_page(pmd_val(*pmd));
+list_add_tail(pt-list, d-arch.mm-pt_list);
+}
+
+return pte_offset_map(pmd, mpaddr);
+}
+
+//XXX xxx_none() should be used instread of !xxx_present()?
+static pte_t*
+lookup_noalloc_domain_pte(struct domain* d, unsigned long mpaddr)
+{
+struct mm_struct *mm = d-arch.mm;
+pgd_t *pgd;
+pud_t *pud;
+pmd_t *pmd;
+
+BUG_ON(mm-pgd == NULL);
+pgd = pgd_offset(mm, mpaddr);
+if (!pgd_present(*pgd))
+goto not_present;
+
+pud = pud_offset(pgd, mpaddr);
+if (!pud_present(*pud))
+goto not_present;
+
+pmd = pmd_offset(pud, mpaddr);
+if (!pmd_present(*pmd))
+goto not_present;
+
+return pte_offset_map(pmd, mpaddr);
+
+not_present:
+return NULL;
+}
+
+#ifdef CONFIG_XEN_IA64_DOM0_VP
+static pte_t*
+lookup_noalloc_domain_pte_none(struct domain* d, unsigned long mpaddr)
+{
+struct mm_struct *mm = d-arch.mm;
+pgd_t *pgd;
+pud_t *pud;
+pmd_t *pmd;
+
+BUG_ON(mm-pgd == NULL);
+pgd = pgd_offset(mm, mpaddr);
+if (pgd_none(*pgd))
+goto not_present;
+
+pud = pud_offset(pgd, mpaddr);
+if (pud_none(*pud))
+goto not_present;
+
+pmd = pmd_offset(pud, mpaddr);
+if (pmd_none(*pmd))
+goto not_present;
+
+return pte_offset_map(pmd, mpaddr);
+
+not_present:
+return NULL;
+}
+#endif
/* Allocate a new page for domain and map it to the specified metaphysical
address. */
-static struct page_info * assign_new_domain_page(struct domain *d, unsigned
long mpaddr)
-{
- unsigned long maddr;
- struct page_info *p;
+struct page_info *
+__assign_new_domain_page(struct domain *d, unsigned long mpaddr, pte_t* pte)
+{
+struct page_info *p = NULL;
+unsigned long maddr;
+
+BUG_ON(!pte_none(*pte));
#ifdef CONFIG_DOMAIN0_CONTIGUOUS
- if (d == dom0) {
- if (mpaddr dom0_start || mpaddr = dom0_start + dom0_size) {
- /* FIXME: is it true ?
- dom0 memory is not contiguous! */
- printk(assign_new_domain_page: bad domain0
- mpaddr=%lx, start=%lx, end=%lx!\n,
- mpaddr, dom0_start, dom0_start+dom0_size);
- while(1);
- }
- p = mfn_to_page((mpaddr PAGE_SHIFT));
- }
- else
-#endif
- {
- p = alloc_domheap_page(d);
- // zero out pages for security reasons
- if (p) memset(__va(page_to_maddr(p)),0,PAGE_SIZE);
- }
- if (unlikely(!p)) {
- printf(assign_new_domain_page: Can't alloc Aaaargh!\n);
- return(p);
- }
- maddr = page_to_maddr (p);
- if (unlikely(maddr __get_cpu_var(vhpt_paddr)
- maddr __get_cpu_var(vhpt_pend))) {
- /* FIXME: how can this happen ?
- vhpt is allocated by alloc_domheap_page. */
- printf(assign_new_domain_page: reassigned vhpt page %lx!!\n,
- maddr);
- }
- assign_domain_page (d, mpaddr, maddr);
- return p;
+if (d == dom0) {
+#if 0
+if (mpaddr dom0_start || mpaddr = dom0_start + dom0_size) {
+/* FIXME: is it true ?
+ dom0 memory is
[Xen-ia64-devel] [PATCH 9/9] [P2M/VP step 1] linux: arch/ia64/xen/makefile change
9 / 9 # HG changeset patch # User [EMAIL PROTECTED] # Node ID a1cb7dec2862f15e9f51a330ec2dd9ae8dc482a9 # Parent ed0baafd91fb6379a9111c6388e6a07c865d6d88 update linux-2.6-xen-sparse/arch/ia64/xen/Makefile PATCHNAME: arch_ia64_xen_makefile_linux Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r ed0baafd91fb -r a1cb7dec2862 linux-2.6-xen-sparse/arch/ia64/xen/Makefile --- a/linux-2.6-xen-sparse/arch/ia64/xen/Makefile Mon Apr 24 22:28:08 2006 +0900 +++ b/linux-2.6-xen-sparse/arch/ia64/xen/Makefile Mon Apr 24 22:28:09 2006 +0900 @@ -3,3 +3,6 @@ # obj-y := hypercall.o xenivt.o xenentry.o xensetup.o xenpal.o xenhpski.o xenconsole.o xen_ksyms.o + +obj-$(CONFIG_XEN_IA64_DOM0_VP) += hypervisor.o pci-dma-xen.o +pci-dma-xen-$(CONFIG_XEN_IA64_DOM0_VP) := ../../i386/kernel/pci-dma-xen.o \ No newline at end of file ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 5/9] [P2M/VP step 1] xen: introduce dom0vp hypercalls
5 / 9
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 9636abaa69590d7284f72c35efc7808d572d9c1b
# Parent 796aadb735e04f2beadcf1bb5be599829099438c
implement dom0vp hypercall.
PATCHNAME: dom0vp_hypercall_xen
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 796aadb735e0 -r 9636abaa6959 xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c Mon Apr 24 22:28:02 2006 +0900
+++ b/xen/arch/ia64/xen/dom0_ops.c Mon Apr 24 22:28:03 2006 +0900
@@ -236,6 +236,55 @@ long arch_do_dom0_op(dom0_op_t *op, GUES
return ret;
}
+#ifdef CONFIG_XEN_IA64_DOM0_VP
+unsigned long
+do_dom0vp_op(unsigned long cmd,
+ unsigned long arg0, unsigned long arg1, unsigned long arg2,
+ unsigned long arg3)
+{
+unsigned long ret = 0;
+struct domain *d = current-domain;
+
+switch (cmd) {
+case IA64_DOM0VP_ioremap:
+ret = assign_domain_mmio_page(d, arg0, arg1);
+break;
+case IA64_DOM0VP_phystomach:
+ret = lookup_domain_mpa(d, arg0 PAGE_SHIFT);
+if (ret == INVALID_MFN) {
+DPRINTK(%s:%d INVALID_MFN ret: 0x%lx\n, __func__, __LINE__, ret);
+} else {
+ret = (ret _PFN_MASK) PAGE_SHIFT;//XXX pte_pfn()
+}
+break;
+case IA64_DOM0VP_machtophys:
+if (max_page = arg0) {
+ret = INVALID_M2P_ENTRY;
+break;
+}
+ret = get_gpfn_from_mfn(arg0);
+break;
+case IA64_DOM0VP_populate_physmap:
+ret = dom0vp_populate_physmap(d, arg0,
+ (unsigned int)arg1, (unsigned int)arg2);
+break;
+case IA64_DOM0VP_zap_physmap:
+ret = dom0vp_zap_physmap(d, arg0, (unsigned int)arg1);
+break;
+case IA64_DOM0VP_add_physmap:
+ret = dom0vp_add_physmap(d, arg0, arg1, (unsigned int)arg2,
+ (domid_t)arg3);
+break;
+default:
+ret = -1;
+ printf(unknown dom0_vp_op 0x%lx\n, cmd);
+break;
+}
+
+return ret;
+}
+#endif
+
/*
* Local variables:
* mode: C
diff -r 796aadb735e0 -r 9636abaa6959 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cMon Apr 24 22:28:02 2006 +0900
+++ b/xen/arch/ia64/xen/domain.cMon Apr 24 22:28:03 2006 +0900
@@ -886,6 +886,151 @@ unsigned long lookup_domain_mpa(struct d
mpafoo(mpaddr);
return 0;
}
+
+#ifdef CONFIG_XEN_IA64_DOM0_VP
+//XXX SMP
+unsigned long
+dom0vp_populate_physmap(struct domain *d, unsigned long gpfn,
+unsigned int extent_order, unsigned int address_bits)
+{
+unsigned long ret = 0;
+int flags = 0;
+unsigned long mpaddr = gpfn PAGE_SHIFT;
+unsigned long extent_size = 1UL extent_order;
+unsigned long offset;
+struct page_info* page;
+unsigned long physaddr;
+
+if (extent_order 0 !multipage_allocation_permitted(d)) {
+ret = -EINVAL;
+goto out;
+}
+
+if (gpfn + (1 extent_order) gpfn) {
+ret = -EINVAL;
+goto out;
+}
+if (gpfn d-max_pages || gpfn + (1 extent_order) d-max_pages) {
+ret = -EINVAL;
+goto out;
+}
+if ((extent_size PAGE_SHIFT) extent_size) {
+ret = -EINVAL;
+goto out;
+}
+
+//XXX check address_bits and set flags = ALLOC_DOM_DMA if needed
+
+// check the rage is not populated yet.
+//XXX loop optimization
+for (offset = 0; offset extent_size PAGE_SHIFT; offset += PAGE_SIZE) {
+if (lookup_domain_mpa(d, mpaddr + offset) != INVALID_MFN) {
+ret = -EBUSY;
+goto out;
+}
+}
+
+page = alloc_domheap_pages(d, extent_order, flags);
+if (page == NULL) {
+ret = -ENOMEM;
+DPRINTK(Could not allocate order=%d extent: id=%d flags=%x\n,
+extent_order, d-domain_id, flags);
+goto out;
+}
+
+//XXX loop optimization
+physaddr = page_to_maddr(page);
+for (offset = 0; offset extent_size PAGE_SHIFT; offset += PAGE_SIZE) {
+assign_domain_page(d, mpaddr + offset, physaddr + offset);
+}
+
+out:
+return ret;
+}
+
+//XXX SMP
+unsigned long
+dom0vp_zap_physmap(struct domain *d, unsigned long gpfn,
+ unsigned int extent_order)
+{
+unsigned long ret = 0;
+if (extent_order != 0) {
+//XXX
+ret = -ENOSYS;
+goto out;
+}
+
+zap_domain_page_one(d, gpfn PAGE_SHIFT);
+
+out:
+return ret;
+}
+
+static void
+assign_domain_page_replace(struct domain *d, unsigned long mpaddr,
+ unsigned long mfn, unsigned int flags)
+{
+struct mm_struct *mm = d-arch.mm;
+pte_t* pte;
+pte_t old_pte;
+
+pte = lookup_alloc_domain_pte(d, mpaddr);
+
+// update pte
+old_pte = ptep_get_and_clear(mm, mpaddr, pte);
+set_pte(pte, pfn_pte(mfn,
+ __pgprot(__DIRTY_BITS | _PAGE_PL_2 | _PAGE_AR_RWX)));
+if (!pte_none(old_pte)) {
+
