Re: [Xen-ia64-devel] save/restore clean up and related bugs
On Mon, May 07, 2007 at 06:09:04PM -0600, Alex Williamson wrote: I still see these pretty regularly after a save/restore (running ia64 cset 15029). I'm testing with a 16G 2-way dom0 and a 4-way 4G domU using an lvm disk. I boot up the domU, save, restore, then an 'ls' in the domU usually triggers a few of them. They tend to work themselves out after a while, so subsequent 'ls' operations usually work fine. Here are the kernel addresses that I've seen trigger these messages on my current test system: I was able to reproduce it with cset 15029. With three outstanding patch, it should be fixed. The two patch which were sent to xen-devel are already in staging tree. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] cleanup warning of UC|WB attributepage
I remade the patch as efi_ucwb() don't check EFI Mermoy Type. If we choice this approch, please apply it. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe cleanup_warning_efi_uc2wb.v3.patch Description: Binary data ___ 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#15029
Xen/IA64 Healthiness Report No issue is found in this changeset. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) PAL version: 8.47 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 14854:039daabebad5 Xen Schedule: credit VTI Guest Firmware Flash.fd.2007.04.11 MD5: 5dc3807812a93b379bb401ebc8cb5641 Summary Test Report: - Total cases: 17 Passed:17 Failed: 0 Detailed Test Case Report: - 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 Win2k3_PV_Test pass Test Win2k3 VTI PV (4vcpu + 1G mem) Notes: - The last stable changeset: - 15029:d1ce60b8070f Best Regards Yongkang ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] make p2m exposure compatible with suspend/resume
The previous patch was imcomplete. Please replace it with this one.
Sorry for confusion.
On Mon, May 07, 2007 at 03:03:50PM +0900, Isaku Yamahata wrote:
This patch depends on the patch I sent to xen-devel
[PATCH] add two arch hooks xen_pre_suspend() and xen_post_suspend()
for suspend/resume.
I forgot to mention it.
On Mon, May 07, 2007 at 02:58:57PM +0900, Isaku Yamahata wrote:
make p2m exposure compatible with suspend/resume
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1178606408 -32400
# Node ID 89b0cc16c053c917adf6219d55356f969b029a38
# Parent d1ce60b8070f640408c702f1fbbef0f6ffda8586
make p2m exposure compatible with suspend/resume and fix one bug.
PATCHNAME: p2m_exposure_suspend_resume
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r d1ce60b8070f -r 89b0cc16c053 linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Mon May 07 13:24:37 2007 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Tue May 08 15:40:08 2007 +0900
@@ -48,6 +48,7 @@ static int p2m_expose_init(void);
static int p2m_expose_init(void);
#else
#define p2m_expose_init() (-ENOSYS)
+#define p2m_expose_resume() ((void)0)
#endif
EXPORT_SYMBOL(__hypercall);
@@ -882,6 +883,9 @@ static struct resource p2m_resource = {
};
static unsigned long p2m_assign_start_pfn __read_mostly;
static unsigned long p2m_assign_end_pfn __read_mostly;
+static unsigned long p2m_expose_size; /* this is referenced only when resume.
+ * so __read_mostly doesn't make sense.
+ */
volatile const pte_t* p2m_pte __read_mostly;
#define GRNULE_PFN PTRS_PER_PTE
@@ -942,8 +946,15 @@ p2m_expose_dtr_call(struct notifier_bloc
unsigned int cpu = (unsigned int)(long)ptr;
if (event != CPU_ONLINE)
return 0;
- if (!(p2m_initialized xen_ia64_p2m_expose_use_dtr))
- smp_call_function_single(cpu, p2m_itr, p2m_itr_arg, 1, 1);
+ if (p2m_initialized xen_ia64_p2m_expose_use_dtr) {
+ unsigned int me = get_cpu();
+ if (cpu == me)
+ p2m_itr(p2m_itr_arg);
+ else
+ smp_call_function_single(cpu, p2m_itr, p2m_itr_arg,
+ 1, 1);
+ put_cpu();
+ }
return 0;
}
@@ -958,7 +969,6 @@ p2m_expose_init(void)
p2m_expose_init(void)
{
unsigned long num_pfn;
- unsigned long size = 0;
unsigned long p2m_size = 0;
unsigned long align = ~0UL;
int error = 0;
@@ -1010,7 +1020,7 @@ p2m_expose_init(void)
p2m_convert_max_pfn = ROUNDUP(p2m_max_low_pfn,
granule_pfn);
num_pfn = p2m_convert_max_pfn - p2m_convert_min_pfn;
- size = num_pfn PAGE_SHIFT;
+ p2m_expose_size = num_pfn PAGE_SHIFT;
p2m_size = num_pfn / PTRS_PER_PTE;
p2m_size = ROUNDUP(p2m_size, granule_pfn PAGE_SHIFT);
if (p2m_size == page_size)
@@ -1030,7 +1040,7 @@ p2m_expose_init(void)
p2m_granule_pfn);
p2m_convert_max_pfn = ROUNDUP(p2m_max_low_pfn, p2m_granule_pfn);
num_pfn = p2m_convert_max_pfn - p2m_convert_min_pfn;
- size = num_pfn PAGE_SHIFT;
+ p2m_expose_size = num_pfn PAGE_SHIFT;
p2m_size = num_pfn / PTRS_PER_PTE;
p2m_size = ROUNDUP(p2m_size, p2m_granule_pfn PAGE_SHIFT);
align = max(privcmd_resource_align,
@@ -1054,14 +1064,14 @@ p2m_expose_init(void)
error = HYPERVISOR_expose_p2m(p2m_convert_min_pfn,
p2m_assign_start_pfn,
- size, p2m_granule_pfn);
+ p2m_expose_size, p2m_granule_pfn);
if (error) {
printk(KERN_ERR P2M_PREFIX failed expose p2m hypercall %d\n,
error);
printk(KERN_ERR P2M_PREFIX conv 0x%016lx assign 0x%016lx
- size 0x%016lx granule 0x%016lx\n,
+ expose_size 0x%016lx granule 0x%016lx\n,
p2m_convert_min_pfn, p2m_assign_start_pfn,
- size, p2m_granule_pfn);;
+ p2m_expose_size, p2m_granule_pfn);;
release_resource(p2m_resource);
goto out;
}
@@ -1104,6 +1114,44 @@ p2m_expose_cleanup(void)
}
#endif
+static void
+p2m_expose_resume(void)
+{
+ int error;
+ if (!xen_ia64_p2m_expose || !p2m_initialized)
+ return;
+
+ // We can't call {lock, unlock}_cpu_hotplug() because
+ // they require process context.
+ // We don't need them because we're the only one cpu and
+ // interrupts are masked when resume.
+ error = HYPERVISOR_expose_p2m(p2m_convert_min_pfn,
+ p2m_assign_start_pfn,
+ p2m_expose_size, p2m_granule_pfn);
+ if (error) {
+ printk(KERN_ERR P2M_PREFIX failed expose p2m hypercall %d\n,
+ error);
+ printk(KERN_ERR P2M_PREFIX conv 0x%016lx assign 0x%016lx
+ expose_size 0x%016lx
[Xen-ia64-devel] Re: PATCH: vpsr handling cleanup
On Mon, May 07, 2007 at 03:35:40PM -0600, Alex Williamson wrote: On Mon, 2007-05-07 at 06:32 +0200, Tristan Gingold wrote: Hi, this is a noop patch: just create a function which really returns the virtual psr and create a new function to set psr for delivering an interrupt. Hi Tristan, It doesn't seem like quite a noop. I'm seeing a pretty significant performance hit as seen by a parallel kernel build in an SMP PV domain (on the order of 20%). I can provide more details if you're unable to reproduce. Thanks, Ok, I will rework it! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] code clean up using xen machine vector.
code clean up using xen machine vector.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1178619507 -32400
# Node ID 1c42e2281e1679d7cd662ecbeb5d929967a2d24a
# Parent 89b0cc16c053c917adf6219d55356f969b029a38
code clean up using xen machine vector.
PATCHNAME: ia64_machine_vector_clean_up
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 89b0cc16c053 -r 1c42e2281e16 linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Tue May 08 15:40:08 2007 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Tue May 08 19:18:27 2007 +0900
@@ -514,6 +514,68 @@ void xen_smp_intr_init(void)
#endif /* CONFIG_SMP */
}
+void
+xen_irq_init(void)
+{
+ struct callback_register event = {
+ .type = CALLBACKTYPE_event,
+ .address = (unsigned long)xen_event_callback,
+ };
+ xen_init_IRQ();
+ BUG_ON(HYPERVISOR_callback_op(CALLBACKOP_register, event));
+ late_time_init = xen_bind_early_percpu_irq;
+#ifdef CONFIG_SMP
+ register_percpu_irq(IA64_IPI_RESCHEDULE, resched_irqaction);
+#endif /* CONFIG_SMP */
+}
+
+void
+xen_platform_send_ipi(int cpu, int vector, int delivery_mode, int redirect)
+{
+ int irq = -1;
+
+#ifdef CONFIG_SMP
+ /* TODO: we need to call vcpu_up here */
+ if (unlikely(vector == ap_wakeup_vector)) {
+ extern void xen_send_ipi (int cpu, int vec);
+
+ /* XXX
+ * This should be in __cpu_up(cpu) in ia64 smpboot.c
+ * like x86. But don't want to modify it,
+ * keep it untouched.
+ */
+ xen_smp_intr_init_early(cpu);
+
+ xen_send_ipi (cpu, vector);
+ //vcpu_prepare_and_up(cpu);
+ return;
+ }
+#endif
+
+ switch(vector) {
+ case IA64_IPI_VECTOR:
+ irq = per_cpu(ipi_to_irq, cpu)[IPI_VECTOR];
+ break;
+ case IA64_IPI_RESCHEDULE:
+ irq = per_cpu(ipi_to_irq, cpu)[RESCHEDULE_VECTOR];
+ break;
+ case IA64_CMCP_VECTOR:
+ irq = per_cpu(ipi_to_irq, cpu)[CMCP_VECTOR];
+ break;
+ case IA64_CPEP_VECTOR:
+ irq = per_cpu(ipi_to_irq, cpu)[CPEP_VECTOR];
+ break;
+ default:
+ printk(KERN_WARNING Unsupported IPI type 0x%x\n,
+ vector);
+ irq = 0;
+ break;
+ }
+
+ BUG_ON(irq 0);
+ notify_remote_via_irq(irq);
+ return;
+}
#endif /* CONFIG_XEN */
void
@@ -541,21 +603,6 @@ void __init
void __init
init_IRQ (void)
{
-#ifdef CONFIG_XEN
- /* Maybe put into platform_irq_init later */
- if (is_running_on_xen()) {
- struct callback_register event = {
- .type = CALLBACKTYPE_event,
- .address = (unsigned long)xen_event_callback,
- };
- xen_init_IRQ();
- BUG_ON(HYPERVISOR_callback_op(CALLBACKOP_register, event));
- late_time_init = xen_bind_early_percpu_irq;
-#ifdef CONFIG_SMP
- register_percpu_irq(IA64_IPI_RESCHEDULE, resched_irqaction);
-#endif /* CONFIG_SMP */
- }
-#endif /* CONFIG_XEN */
register_percpu_irq(IA64_SPURIOUS_INT_VECTOR, NULL);
#ifdef CONFIG_SMP
register_percpu_irq(IA64_IPI_VECTOR, ipi_irqaction);
@@ -564,6 +611,10 @@ init_IRQ (void)
pfm_init_percpu();
#endif
platform_irq_init();
+#ifdef CONFIG_XEN
+ if (is_running_on_xen() !ia64_platform_is(xen))
+ xen_irq_init();
+#endif
}
void
@@ -574,52 +625,11 @@ ia64_send_ipi (int cpu, int vector, int
unsigned long phys_cpu_id;
#ifdef CONFIG_XEN
-if (is_running_on_xen()) {
- int irq = -1;
-
-#ifdef CONFIG_SMP
- /* TODO: we need to call vcpu_up here */
- if (unlikely(vector == ap_wakeup_vector)) {
- extern void xen_send_ipi (int cpu, int vec);
-
- /* XXX
- * This should be in __cpu_up(cpu) in ia64 smpboot.c
- * like x86. But don't want to modify it,
- * keep it untouched.
- */
- xen_smp_intr_init_early(cpu);
-
- xen_send_ipi (cpu, vector);
- //vcpu_prepare_and_up(cpu);
- return;
- }
-#endif
-
- switch(vector) {
- case IA64_IPI_VECTOR:
- irq = per_cpu(ipi_to_irq, cpu)[IPI_VECTOR];
- break;
- case IA64_IPI_RESCHEDULE:
- irq = per_cpu(ipi_to_irq, cpu)[RESCHEDULE_VECTOR];
- break;
- case IA64_CMCP_VECTOR:
- irq = per_cpu(ipi_to_irq, cpu)[CMCP_VECTOR];
- break;
- case IA64_CPEP_VECTOR:
- irq = per_cpu(ipi_to_irq, cpu)[CPEP_VECTOR];
- break;
- default:
- printk(KERN_WARNING Unsupported IPI type 0x%x\n,
- vector);
- irq = 0;
- break;
- }
-
- BUG_ON(irq 0);
- notify_remote_via_irq(irq);
+ if (is_running_on_xen()) {
+ xen_platform_send_ipi(cpu, vector, delivery_mode, redirect);
return;
-}
-#endif /* CONFIG_XEN */
+ }
+#endif
#ifdef CONFIG_SMP
phys_cpu_id = cpu_physical_id(cpu);
diff -r 89b0cc16c053 -r 1c42e2281e16 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Tue May 08 15:40:08 2007 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Tue May 08 19:18:27 2007 +0900
@@ -603,7 +603,10 @@ setup_arch (char **cmdline_p)
platform_setup(cmdline_p);
#ifdef CONFIG_XEN
- xen_setup();
+ if (!is_running_on_xen() !ia64_platform_is(xen)) {
+ extern ia64_mv_setup_t xen_setup;
+ xen_setup(cmdline_p);
+ }
#endif
paging_init();
#ifdef CONFIG_XEN
@@ -993,12 +996,10 @@ cpu_init (void)
/* size of physical
[Xen-ia64-devel] Re: [Xen-devel] [RFC] [0/4] User-space grants for Console and XenStore
On Tue, May 08, 2007 at 03:40:41PM +0100, Derek Murray wrote: On 7 May 2007, at 09:46, Isaku Yamahata wrote: On Wed, May 02, 2007 at 12:15:18PM +0100, Derek Murray wrote: * Will this work on ia64 and PowerPC? With the attached patches, I was able to boot dom0 and create/ destroy domU. I used gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2). Thanks for these patches! I'll incorporate them into the revised version of my patchset. It's good to know that gntdev is working on these architectures. I forgot to say that I only tested on IA64. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: cleanup in faults.c
Hi,
a small cleanup pass.
Checked by compiling only.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1178629671 -7200
# Node ID 8519e5db6510a066788bb525a17588bad3674203
# Parent d1ce60b8070f640408c702f1fbbef0f6ffda8586
Cleanup: more static added, unused functions removed, a typo fixed.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r d1ce60b8070f -r 8519e5db6510 xen/arch/ia64/xen/faults.c
--- a/xen/arch/ia64/xen/faults.cMon May 07 13:24:37 2007 -0600
+++ b/xen/arch/ia64/xen/faults.cTue May 08 15:07:51 2007 +0200
@@ -54,8 +54,9 @@ extern void do_ssc(unsigned long ssc, st
extern void do_ssc(unsigned long ssc, struct pt_regs *regs);
// should never panic domain... if it does, stack may have been overrun
-void check_bad_nested_interruption(unsigned long isr, struct pt_regs *regs,
- unsigned long vector)
+static void check_bad_nested_interruption(unsigned long isr,
+ struct pt_regs *regs,
+ unsigned long vector)
{
struct vcpu *v = current;
@@ -74,8 +75,8 @@ void check_bad_nested_interruption(unsig
}
}
-void reflect_interruption(unsigned long isr, struct pt_regs *regs,
- unsigned long vector)
+static void reflect_interruption(unsigned long isr, struct pt_regs *regs,
+unsigned long vector)
{
struct vcpu *v = current;
@@ -101,26 +102,6 @@ void reflect_interruption(unsigned long
PSCB(v, interrupt_collection_enabled) = 0;
perfc_incra(slow_reflect, vector 8);
-}
-
-static unsigned long pending_false_positive = 0;
-
-void reflect_extint(struct pt_regs *regs)
-{
- unsigned long isr = regs-cr_ipsr IA64_PSR_RI;
- struct vcpu *v = current;
- static int first_extint = 1;
-
- if (first_extint) {
- printk(Delivering first extint to domain: isr=0x%lx,
- iip=0x%lx\n, isr, regs-cr_iip);
- first_extint = 0;
- }
- if (vcpu_timer_pending_early(v))
- printk(*#*#*#* about to deliver early timer to domain %d!!\n,
- v-domain-domain_id);
- PSCB(current, itir) = 0;
- reflect_interruption(isr, regs, IA64_EXTINT_VECTOR);
}
void reflect_event(void)
@@ -164,22 +145,6 @@ void reflect_event(void)
PSCB(v, vpsr_dfh) = 0;
v-vcpu_info-evtchn_upcall_mask = 1;
PSCB(v, interrupt_collection_enabled) = 0;
-}
-
-// ONLY gets called from ia64_leave_kernel
-// ONLY call with interrupts disabled?? (else might miss one?)
-// NEVER successful if already reflecting a trap/fault because psr.i==0
-void deliver_pending_interrupt(struct pt_regs *regs)
-{
- struct domain *d = current-domain;
- struct vcpu *v = current;
- // FIXME: Will this work properly if doing an RFI???
- if (!is_idle_domain(d) user_mode(regs)) {
- if (vcpu_deliverable_interrupts(v))
- reflect_extint(regs);
- else if (PSCB(v, pending_interruption))
- ++pending_false_positive;
- }
}
static int handle_lazy_cover(struct vcpu *v, struct pt_regs *regs)
@@ -593,7 +558,7 @@ ia64_handle_reflection(unsigned long ifa
unsigned long psr = regs-cr_ipsr;
unsigned long status;
- /* Following faults shouldn'g be seen from Xen itself */
+ /* Following faults shouldn't be seen from Xen itself */
BUG_ON(!(psr IA64_PSR_CPL));
switch (vector) {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] cleanup warning of UC|WB attributepage
On Tue, 2007-05-08 at 09:58 +0900, Akio Takebe wrote: BTW, I also thought another approch to prevent these case. Because these memory area is accessed as both UC and WB, we need to use new flag. (For example _PAGE_MA_UCE, I'm not sure we can use this flag for UC|WB. or should we make new flag?) In consideration of stability, I didn't make new flag. (Because I must check many part of memory access.) Which approch do you prefer? or another suggestion? That does sound rather involved. Unless others think the UCE page is a better way to go, perhaps we should use something like the approach you're suggesting. Newer upstream efi.c has a efi_mem_attribute() function that will give you the attributes for a given range of memory. Rather than implementing yet another EFI memmap walking routine, what do you think about updating efi.c to a newer upstream version and making use of this function? 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] make p2m exposure compatible with suspend/resume
On Tue, May 08, 2007 at 03:41:19PM +0900, Isaku Yamahata wrote: The previous patch was imcomplete. Please replace it with this one. Hi Isaku, you should really define the TR used by the p2m in kregs.h. Using a define is less error-prone than a hard coded number (0x2). (I don't object against this specific patch as the hard-coded number use is already commited in the tree). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: define guest_mode (instead of user_mode)
Hi,
subject says all; xen-x86 already defines this macro.
Tested only by compilation.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1178630697 -7200
# Node ID 8e5083feaa526653ae9b95b1d4117eb8066bbf35
# Parent 8519e5db6510a066788bb525a17588bad3674203
Defined guest_mode and use it instead of user_mode.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 8519e5db6510 -r 8e5083feaa52 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Tue May 08 15:07:51 2007 +0200
+++ b/xen/arch/ia64/vmx/vmx_process.c Tue May 08 15:24:57 2007 +0200
@@ -164,7 +164,7 @@ vmx_ia64_handle_break (unsigned long ifa
if (iim == 0)
vmx_die_if_kernel(Break 0 in Hypervisor., regs, iim);
-if (!user_mode(regs)) {
+if (ia64_psr(regs)-cpl == 0) {
/* Allow hypercalls only when cpl = 0. */
if (iim == d-arch.breakimm) {
ia64_hypercall(regs);
diff -r 8519e5db6510 -r 8e5083feaa52 xen/arch/ia64/xen/faults.c
--- a/xen/arch/ia64/xen/faults.cTue May 08 15:07:51 2007 +0200
+++ b/xen/arch/ia64/xen/faults.cTue May 08 15:24:57 2007 +0200
@@ -209,7 +209,7 @@ void ia64_do_page_fault(unsigned long ad
if (is_ptc_l_needed)
vcpu_ptc_l(current, address, logps);
- if (!user_mode(regs)) {
+ if (!guest_mode(regs)) {
/* The fault occurs inside Xen. */
if (!ia64_done_with_exception(regs)) {
// should never happen. If it does, region 0 addr may
diff -r 8519e5db6510 -r 8e5083feaa52 xen/arch/ia64/xen/xenmisc.c
--- a/xen/arch/ia64/xen/xenmisc.c Tue May 08 15:07:51 2007 +0200
+++ b/xen/arch/ia64/xen/xenmisc.c Tue May 08 15:24:57 2007 +0200
@@ -79,7 +79,7 @@ void console_print(char *msg)
void die_if_kernel(char *str, struct pt_regs *regs, long err)
{
- if (user_mode(regs))
+ if (guest_mode(regs))
return;
printk(%s: %s %ld\n, __func__, str, err);
diff -r 8519e5db6510 -r 8e5083feaa52 xen/include/asm-ia64/linux-xen/asm/ptrace.h
--- a/xen/include/asm-ia64/linux-xen/asm/ptrace.h Tue May 08 15:07:51
2007 +0200
+++ b/xen/include/asm-ia64/linux-xen/asm/ptrace.h Tue May 08 15:24:57
2007 +0200
@@ -265,7 +265,11 @@ struct switch_stack {
/* given a pointer to a task_struct, return the user's pt_regs */
# define ia64_task_regs(t) (((struct pt_regs *) ((char *) (t) +
IA64_STK_OFFSET)) - 1)
# define ia64_psr(regs)((struct ia64_psr *)
(regs)-cr_ipsr)
+#ifdef XEN
+# define guest_mode(regs) (ia64_psr(regs)-cpl != 0)
+#else
# define user_mode(regs) (((struct ia64_psr *)
(regs)-cr_ipsr)-cpl != 0)
+#endif
# define user_stack(task,regs) ((long) regs - (long) task == IA64_STK_OFFSET -
sizeof(*regs))
# define fsys_mode(task,regs) \
({ \
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] psr.sp/is/di/si virtualization
Hi, these psr bits are not fully virtualized and the current usage is not clear (at least to me): sp (secure performance monitor): I don't know how it is currently used by xenoprofile. Isaku have you any tips on it ? di (disable instruction set transition): should it be hard-coded to 1 or should it be settable by the kernel ? si (secure interval timer): should be forced to 0? is (instruction set): same use as di. mc (machine check): should be forced to 1? vm: should be forced to 0. Comments are welcome! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: define guest_mode (instead of user_mode)
On Tue, 2007-05-08 at 15:26 +0200, Tristan Gingold wrote:
diff -r 8519e5db6510 -r 8e5083feaa52 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Tue May 08 15:07:51 2007 +0200
+++ b/xen/arch/ia64/vmx/vmx_process.c Tue May 08 15:24:57 2007 +0200
@@ -164,7 +164,7 @@ vmx_ia64_handle_break (unsigned long ifa
if (iim == 0)
vmx_die_if_kernel(Break 0 in Hypervisor., regs, iim);
-if (!user_mode(regs)) {
+if (ia64_psr(regs)-cpl == 0) {
Why is this first one a special case? ie. why not !guest_mode(regs)
same as the next one? Thanks,
Alex
/* Allow hypercalls only when cpl = 0. */
if (iim == d-arch.breakimm) {
ia64_hypercall(regs);
diff -r 8519e5db6510 -r 8e5083feaa52 xen/arch/ia64/xen/faults.c
--- a/xen/arch/ia64/xen/faults.cTue May 08 15:07:51 2007 +0200
+++ b/xen/arch/ia64/xen/faults.cTue May 08 15:24:57 2007 +0200
@@ -209,7 +209,7 @@ void ia64_do_page_fault(unsigned long ad
if (is_ptc_l_needed)
vcpu_ptc_l(current, address, logps);
- if (!user_mode(regs)) {
+ if (!guest_mode(regs)) {
--
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] code clean up using xen machine vector.
On Tue, 2007-05-08 at 19:25 +0900, Isaku Yamahata wrote: code clean up using xen machine vector. Nice cleanup, that machine vector is working out already. 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
[Xen-ia64-devel] Re: PATCH: cleanup in faults.c
On Tue, 2007-05-08 at 15:08 +0200, Tristan Gingold wrote: Hi, a small cleanup pass. Checked by compiling only. 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] cleanup warning of UC|WB attributepage
Hi, Alex On Tue, 2007-05-08 at 09:58 +0900, Akio Takebe wrote: BTW, I also thought another approch to prevent these case. Because these memory area is accessed as both UC and WB, we need to use new flag. (For example _PAGE_MA_UCE, I'm not sure we can use this flag for UC|WB. or should we make new flag?) In consideration of stability, I didn't make new flag. (Because I must check many part of memory access.) Which approch do you prefer? or another suggestion? That does sound rather involved. Unless others think the UCE page is a better way to go, perhaps we should use something like the approach you're suggesting. Newer upstream efi.c has a efi_mem_attribute() function that will give you the attributes for a given range of memory. Rather than implementing yet another EFI memmap walking routine, what do you think about updating efi.c to a newer upstream version and making use of this function? Thanks, Thank you for your comments. I'll check whether It is possible easy to port new efi.c to xen. Best Regards, Akio Takebe ___ 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#15044
Xen/IA64 Healthiness Report Nightly testing doesn't find any issue. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core and HT) PAL version: 8.47 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 14854:039daabebad5 Xen Schedule: credit VTI Guest Firmware Flash.fd.2007.04.11 MD5: 5dc3807812a93b379bb401ebc8cb5641 Summary Test Report: - Total cases: 17 Passed:17 Failed: 0 Detailed Test Case Report: - 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 Win2k3_PV_Test pass Test Win2k3 VTI PV (4vcpu, 1G mem) Notes: - The last stable changeset: - 15044:eabda101b0c5 Best Regards Yongkang ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] psr.sp/is/di/si virtualization
On Tue, May 08, 2007 at 03:38:38PM +0200, Tristan Gingold wrote: these psr bits are not fully virtualized and the current usage is not clear (at least to me): sp (secure performance monitor): I don't know how it is currently used by xenoprofile. Isaku have you any tips on it ? The current xenoprofile model is that xen vmm controls pmc/pmd. So xenoprof needs to prevent the guest os changing psr.up bit (user pserfomance monitor enable) by setting pser.sp. When considering pmc/pmd virtualization, the xenoprof requirement should be revised. How the virtualization coexist with xenoprof should be considered. di (disable instruction set transition): should it be hard-coded to 1 or should it be settable by the kernel ? si (secure interval timer): should be forced to 0? Vanilla Linux/ia64 sets psr.si = 0 so that application can read it without kernel intervention. But I don't know how many application expect this fact. Probably only benchmarking apps? is (instruction set): same use as di. mc (machine check): should be forced to 1? Or dom0 desires to change? -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] make p2m exposure compatible with suspend/resume
On Tue, May 08, 2007 at 03:32:22PM +0200, Tristan Gingold wrote: you should really define the TR used by the p2m in kregs.h. Using a define is less error-prone than a hard coded number (0x2). (I don't object against this specific patch as the hard-coded number use is already commited in the tree). 0x2 means DTR (and 0x1 means ITR). not index to TR. I agree that ia64_ptr(), ia64_itr() and ia64_itc() should use symbolical definition. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: define guest_mode (instead of user_mode)
On Tue, May 08, 2007 at 10:57:42AM -0600, Alex Williamson wrote:
On Tue, 2007-05-08 at 15:26 +0200, Tristan Gingold wrote:
diff -r 8519e5db6510 -r 8e5083feaa52 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Tue May 08 15:07:51 2007 +0200
+++ b/xen/arch/ia64/vmx/vmx_process.c Tue May 08 15:24:57 2007 +0200
@@ -164,7 +164,7 @@ vmx_ia64_handle_break (unsigned long ifa
if (iim == 0)
vmx_die_if_kernel(Break 0 in Hypervisor., regs, iim);
-if (!user_mode(regs)) {
+if (ia64_psr(regs)-cpl == 0) {
Why is this first one a special case? ie. why not !guest_mode(regs)
same as the next one? Thanks,
This is VTi code. In my opinion, guest_mode makes sense only in PV mode.
Here we are testing wether kernel code is executing and not wether guest is.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] make p2m exposure compatible with suspend/resume
On Wed, May 09, 2007 at 12:02:44PM +0900, Isaku Yamahata wrote: On Tue, May 08, 2007 at 03:32:22PM +0200, Tristan Gingold wrote: you should really define the TR used by the p2m in kregs.h. Using a define is less error-prone than a hard coded number (0x2). (I don't object against this specific patch as the hard-coded number use is already commited in the tree). 0x2 means DTR (and 0x1 means ITR). not index to TR. You're right, I read too quickly! I agree that ia64_ptr(), ia64_itr() and ia64_itc() should use symbolical definition. Yes, but this is linux code. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: rewrite vcpu_get_psr
Hi,
a stripped-down version of a previous patch: reimplement vcpu_get_psr.
Should be a noop, I don't think performance should be affected.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1178683685 -7200
# Node ID 00b887a409dc883f2bae05da7fe8d80f90d430ad
# Parent eabda101b0c54ac51d4a7d335e45144425ca2fda
Reimplement vcpu_get_psr. It now returns the virtualized psr.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r eabda101b0c5 -r 00b887a409dc xen/arch/ia64/xen/privop.c
--- a/xen/arch/ia64/xen/privop.cTue May 08 13:12:52 2007 -0600
+++ b/xen/arch/ia64/xen/privop.cWed May 09 06:08:05 2007 +0200
@@ -524,7 +524,7 @@ static IA64FAULT priv_mov_from_psr(VCPU
u64 val;
IA64FAULT fault;
- fault = vcpu_get_psr(vcpu, val);
+ fault = vcpu_get_psr_masked(vcpu, val);
if (fault == IA64_NO_FAULT)
return vcpu_set_gr(vcpu, tgt, val, 0);
else
@@ -883,7 +883,7 @@ int ia64_hyperprivop(unsigned long iim,
vcpu_reset_psr_sm(v, IA64_PSR_BE);
return 1;
case HYPERPRIVOP_GET_PSR:
- vcpu_get_psr(v, val);
+ vcpu_get_psr_masked(v, val);
regs-r8 = val;
return 1;
}
diff -r eabda101b0c5 -r 00b887a409dc xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Tue May 08 13:12:52 2007 -0600
+++ b/xen/arch/ia64/xen/vcpu.c Wed May 09 06:08:05 2007 +0200
@@ -448,43 +448,49 @@ IA64FAULT vcpu_set_psr_l(VCPU * vcpu, u6
return IA64_NO_FAULT;
}
-IA64FAULT vcpu_get_psr(VCPU * vcpu, u64 * pval)
-{
- REGS *regs = vcpu_regs(vcpu);
- struct ia64_psr newpsr;
-
- newpsr = *(struct ia64_psr *)regs-cr_ipsr;
- if (!vcpu-vcpu_info-evtchn_upcall_mask)
- newpsr.i = 1;
- else
- newpsr.i = 0;
- if (PSCB(vcpu, interrupt_collection_enabled))
- newpsr.ic = 1;
- else
- newpsr.ic = 0;
- if (PSCB(vcpu, metaphysical_mode))
- newpsr.dt = 0;
- else
- newpsr.dt = 1;
- if (PSCB(vcpu, vpsr_pp))
- newpsr.pp = 1;
- else
- newpsr.pp = 0;
- newpsr.dfh = PSCB(vcpu, vpsr_dfh);
-
- *pval = *(unsigned long *)newpsr;
- *pval = (MASK(0, 32) | MASK(35, 2));
- return IA64_NO_FAULT;
-}
-
-BOOLEAN vcpu_get_psr_ic(VCPU * vcpu)
-{
- return !!PSCB(vcpu, interrupt_collection_enabled);
-}
-
-BOOLEAN vcpu_get_psr_i(VCPU * vcpu)
-{
- return !vcpu-vcpu_info-evtchn_upcall_mask;
+u64 vcpu_get_psr(VCPU * vcpu)
+{
+ REGS *regs = vcpu_regs(vcpu);
+ PSR newpsr;
+ PSR ipsr;
+
+ ipsr.i64 = regs-cr_ipsr;
+
+ /* Copy non-virtualized bits. */
+ newpsr.i64 = ipsr.i64 (IA64_PSR_BE | IA64_PSR_UP | IA64_PSR_AC
+| IA64_PSR_MFL | IA64_PSR_MFH
+| IA64_PSR_PK
+| IA64_PSR_DFL | IA64_PSR_SP
+| IA64_PSR_DB | IA64_PSR_LP | IA64_PSR_TB
+| IA64_PSR_ID | IA64_PSR_DA | IA64_PSR_DD
+| IA64_PSR_SS | IA64_PSR_RI | IA64_PSR_ED
+| IA64_PSR_IA);
+
+ /* Bits forced to 1 (psr.si and psr.is are forced to 0) */
+ newpsr.i64 |= IA64_PSR_DI | IA64_PSR_MC;
+
+ /* System mask. */
+ newpsr.ia64_psr.ic = PSCB(vcpu, interrupt_collection_enabled);
+ newpsr.ia64_psr.i = !vcpu-vcpu_info-evtchn_upcall_mask;
+
+ if (!PSCB(vcpu, metaphysical_mode))
+ newpsr.i64 |= IA64_PSR_DT | IA64_PSR_RT | IA64_PSR_IT;
+ newpsr.ia64_psr.dfh = PSCB(vcpu, vpsr_dfh);
+ newpsr.ia64_psr.pp = PSCB(vcpu, vpsr_pp);
+
+ /* Fool cpl. */
+ if (ipsr.ia64_psr.cpl 3)
+ newpsr.ia64_psr.cpl = 0;
+ newpsr.ia64_psr.bn = PSCB(vcpu, banknum);
+
+ return newpsr.i64;
+}
+
+IA64FAULT vcpu_get_psr_masked(VCPU * vcpu, u64 * pval)
+{
+ u64 psr = vcpu_get_psr(vcpu);
+ *pval = psr (MASK(0, 32) | MASK(35, 2));
+ return IA64_NO_FAULT;
}
u64 vcpu_get_ipsr_int_state(VCPU * vcpu, u64 prevpsr)
@@ -509,6 +515,16 @@ u64 vcpu_get_ipsr_int_state(VCPU * vcpu,
// psr.pk = 1;
//printk(returns 0x%016lx...\n,psr.i64);
return psr.i64;
+}
+
+BOOLEAN vcpu_get_psr_ic(VCPU * vcpu)
+{
+ return !!PSCB(vcpu, interrupt_collection_enabled);
+}
+
+BOOLEAN vcpu_get_psr_i(VCPU * vcpu)
+{
+ return !vcpu-vcpu_info-evtchn_upcall_mask;
}
/**
diff -r eabda101b0c5 -r 00b887a409dc xen/include/asm-ia64/vcpu.h
--- a/xen/include/asm-ia64/vcpu.h Tue May 08 13:12:52 2007 -0600
+++ b/xen/include/asm-ia64/vcpu.h Wed May 09 06:08:05 2007 +0200
@@ -42,7 +42,8 @@ extern IA64FAULT vcpu_get_ar(VCPU * vcpu
/* psr */
extern BOOLEAN vcpu_get_psr_ic(VCPU * vcpu);
extern u64
[Xen-ia64-devel] PATCH: vcpu_set_psr
Hi,
this patch implements vcpu_set_psr, which is called by vcpu_rfi.
I hope performance shouldn't be affected.
This implementation also fixes some incorrect assumptions in vcpu_rfi
(such as bn=1, ic = 1...).
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1178686663 -7200
# Node ID 0b1e482b15190f39206d6d34745151197304121b
# Parent 00b887a409dc883f2bae05da7fe8d80f90d430ad
vcpu_set_psr written (and called by vcpu_rfi).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 00b887a409dc -r 0b1e482b1519 xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Wed May 09 06:08:05 2007 +0200
+++ b/xen/arch/ia64/xen/vcpu.c Wed May 09 06:57:43 2007 +0200
@@ -448,6 +448,63 @@ IA64FAULT vcpu_set_psr_l(VCPU * vcpu, u6
return IA64_NO_FAULT;
}
+IA64FAULT vcpu_set_psr(VCPU * vcpu, u64 val)
+{
+ IA64_PSR newpsr, vpsr;
+ REGS *regs = vcpu_regs(vcpu);
+ u64 enabling_interrupts = 0;
+
+ /* Copy non-virtualized bits. */
+ newpsr.val = val (IA64_PSR_BE | IA64_PSR_UP | IA64_PSR_AC
+ | IA64_PSR_MFL | IA64_PSR_MFH
+ | IA64_PSR_PK
+ | IA64_PSR_DFL | IA64_PSR_SP
+ | IA64_PSR_DB | IA64_PSR_LP | IA64_PSR_TB
+ | IA64_PSR_ID | IA64_PSR_DA | IA64_PSR_DD
+ | IA64_PSR_SS | IA64_PSR_RI | IA64_PSR_ED
+ | IA64_PSR_IA);
+
+ /* Bits forced to 1 (psr.si, psr.is and psr.mc are forced to 0) */
+ newpsr.val |= IA64_PSR_DI;
+
+ newpsr.val |= IA64_PSR_I | IA64_PSR_IC
+ | IA64_PSR_DT | IA64_PSR_RT | IA64_PSR_IT
+ | IA64_PSR_BN | IA64_PSR_DI | IA64_PSR_PP;
+
+ vpsr.val = val;
+ if (val IA64_PSR_DFH) {
+ newpsr.dfh = 1;
+ PSCB(vcpu, vpsr_dfh) = 1;
+ } else {
+ newpsr.dfh = PSCB(vcpu, hpsr_dfh);
+ PSCB(vcpu, vpsr_dfh) = 0;
+ }
+ PSCB(vcpu, vpsr_pp) = vpsr.pp;
+ if (vpsr.i) {
+ if (vcpu-vcpu_info-evtchn_upcall_mask)
+ enabling_interrupts = 1;
+ vcpu-vcpu_info-evtchn_upcall_mask = 0;
+ if (enabling_interrupts
+ vcpu_check_pending_interrupts(vcpu) != SPURIOUS_VECTOR)
+ PSCB(vcpu, pending_interruption) = 1;
+ }
+ else
+ vcpu-vcpu_info-evtchn_upcall_mask = 1;
+ PSCB(vcpu, interrupt_collection_enabled) = vpsr.ic;
+ vcpu_set_metaphysical_mode(vcpu, !(vpsr.dt vpsr.rt vpsr.it));
+
+ newpsr.cpl |= vpsr.cpl | 2;
+
+ if (PSCB(vcpu, banknum) != vpsr.bn) {
+ if (vpsr.bn)
+ vcpu_bsw1(vcpu);
+ else
+ vcpu_bsw0(vcpu);
+ }
+ regs-cr_ipsr = newpsr.val;
+ return IA64_NO_FAULT;
+}
+
u64 vcpu_get_psr(VCPU * vcpu)
{
REGS *regs = vcpu_regs(vcpu);
@@ -1349,44 +1406,17 @@ IA64FAULT vcpu_force_data_miss(VCPU * vc
IA64FAULT vcpu_rfi(VCPU * vcpu)
{
- // TODO: Only allowed for current vcpu
- PSR psr;
- u64 int_enable, ifs;
+ u64 ifs;
REGS *regs = vcpu_regs(vcpu);
-
- psr.i64 = PSCB(vcpu, ipsr);
- if (psr.ia64_psr.cpl 3)
- psr.ia64_psr.cpl = 2;
- int_enable = psr.ia64_psr.i;
- if (psr.ia64_psr.dfh) {
- PSCB(vcpu, vpsr_dfh) = 1;
- } else {
- psr.ia64_psr.dfh = PSCB(vcpu, hpsr_dfh);
- PSCB(vcpu, vpsr_dfh) = 0;
- }
- if (psr.ia64_psr.ic)
- PSCB(vcpu, interrupt_collection_enabled) = 1;
- if (psr.ia64_psr.dt psr.ia64_psr.rt psr.ia64_psr.it)
- vcpu_set_metaphysical_mode(vcpu, FALSE);
- else
- vcpu_set_metaphysical_mode(vcpu, TRUE);
- psr.ia64_psr.ic = 1;
- psr.ia64_psr.i = 1;
- psr.ia64_psr.dt = 1;
- psr.ia64_psr.rt = 1;
- psr.ia64_psr.it = 1;
- psr.ia64_psr.bn = 1;
- //psr.pk = 1; // checking pkeys shouldn't be a problem but seems broken
+
+ vcpu_set_psr(vcpu, PSCB(vcpu, ipsr));
ifs = PSCB(vcpu, ifs);
if (ifs 0x8000UL)
regs-cr_ifs = ifs;
- regs-cr_ipsr = psr.i64;
regs-cr_iip = PSCB(vcpu, iip);
- PSCB(vcpu, interrupt_collection_enabled) = 1;
- vcpu_bsw1(vcpu);
- vcpu-vcpu_info-evtchn_upcall_mask = !int_enable;
+
return IA64_NO_FAULT;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
