Re: [PATCH] Fix mca handler so as not to destroy ar(was: Re: [Xen-ia64-devel] Re: mca handler)
On Fri, Jul 25, 2008 at 05:47:37PM +0900, SUZUKI Kazuhiro wrote: The following patch fixes the mca handler so as not to destroy ar and some bugs. Thank you for fixing some bugs and it looks basically good. Some comments below. @@ -524,24 +457,111 @@ ia64_reload_tr: srlz.d ;; #ifdef XEN -.reload_vhpt: - // 5. VHPT - GET_THIS_PADDR(r1, inserted_vhpt);; - cmp.eq p7,p0=r2,r0 -(p7) br.cond.sptk.overlap_vhpt // vhpt isn't mapped. + // 5. shared_info + GET_THIS_PADDR(r2, inserted_shared_info);; + ld8 r16=[r2] + mov r18=XSI_SHIFT2 + movl r20=__pgprot(__DIRTY_BITS | _PAGE_PL_PRIV | _PAGE_AR_RW) + ;; + GET_THIS_PADDR(r2, domain_shared_info);; + ld8 r17=[r2] + ;; + dep r17=0,r17,60,4 + ;; + or r17=r17,r20 // construct PA | page properties + mov cr.itir=r18 + mov cr.ifa=r16 + ;; + mov r16=IA64_TR_SHARED_INFO + ;; + itr.d dtr[r16]=r17 // wire in new mapping... + ;; + srlz.d + ;; Unconditionally pinning down shared_info into inserted_shared_info is wrong because shared_info is shared only with PV domain and xen VMM. So In VMX domain case, it shouldn't pinned down. Otherwise VMX guest wrongly accesses to shared_info. In ia64_do_tlb_purge() case, unconditionally purging DTR[IA64_TR_SHARED_INFO] is okay, but unconditionally inserting DTR[IA64_TR_SHARED_INFO] is bad. thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][LINUX] Support timer vector IPIs in PV code
On Thu, Jul 24, 2008 at 12:28:27PM -0600, Alex Williamson wrote: Upstream Linux recently added this change: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3463a93def55c309f3c0d0a8aaf216be3be42d64 Now, for a platform bug check, we issue an IPI for the IA64_TIMER_VECTOR and wait for it to show up in the IRR. Since a PV kernel doesn't support a timer IPI, this never happens. The fix is simply to tie this into xen_send_ipi() for this case. This doesn't actually happen on 2.6.18, but since vendors are backporting changes from upstream, I think it's good to have this in the reference tree. Thanks, Alex Add support for IA64_TIMER_VECTOR as a paravirtualized IPI target Necessary for the latest upstream Linux implementation of check_sal_cache_flush() 3463a93def55c309f3c0d0a8aaf216be3be42d64 Signed-off-by: Alex Williamson [EMAIL PROTECTED] Applied, thanks. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [PATCH] Fix mca handler so as not to destroy ar(was: Re: [Xen-ia64-devel] Re: mca handler)
On Fri, Jul 25, 2008 at 05:47:37PM +0900, SUZUKI Kazuhiro wrote:
diff -r 1970781956c7 xen/include/asm-ia64/linux-xen/asm/mca_asm.h
--- a/xen/include/asm-ia64/linux-xen/asm/mca_asm.hWed Jul 23 12:10:20
2008 +0900
+++ b/xen/include/asm-ia64/linux-xen/asm/mca_asm.hThu Jul 24 11:08:11
2008 +0900
@@ -58,8 +58,35 @@
#endif
#ifdef XEN
+/*
+ * void set_per_cpu_data(*ret)
+ * {
+ * int i;
+ * for (i = 0; i 64; i++) {
+ * if (ia64_mca_tlb_list[i].cr_lid == ia64_getreg(_IA64_REG_CR_LID)) {
+ * *ret = ia64_mca_tlb_list[i].percpu_paddr;
+ * return;
+ * }
+ * }
+ * while(1); // Endless loop on error
+ * }
+ */
+#define SET_PER_CPU_DATA(reg,_tmp1,_tmp2,_tmp3) \
+ LOAD_PHYSICAL(p0,reg,ia64_mca_tlb_list);;\
+ mov _tmp1 = ar.lc;; \
+ mov ar.lc = NR_CPUS-1; \
+ mov _tmp2 = cr.lid;;\
+10: ld8 _tmp3 = [reg],16;; \
+ cmp.ne p6, p7 = _tmp3, _tmp2;; \
+(p7) br.cond.dpnt 30f;; \
+ br.cloop.sptk.few 10b;; \
+20: br 20b;;/* Endless loop on error */ \
+30: mov ar.lc = _tmp1; \
+ adds reg = IA64_MCA_PERCPU_OFFSET-16, reg;;\
+ ld8 reg = [reg]
+
#define GET_THIS_PADDR(reg, var) \
- mov reg = IA64_KR(PER_CPU_DATA);; \
+ SET_PER_CPU_DATA(reg,r5,r6,r7);;\
addlreg = THIS_CPU(var) - PERCPU_ADDR, reg
#else
#define GET_THIS_PADDR(reg, var) \
Please do not use magic number 16.
IA64_MCA_TLB_INFO_SIZE?
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] domU crashed when LTP was running
On Fri, Jul 25, 2008 at 07:28:24PM +0900, KUWAMURA Shin'ya wrote:
Hi,
Thank you for your patch. This issue was fixed.
But I have a question.
From: Isaku Yamahata [EMAIL PROTECTED]
Subject: Re: [Xen-ia64-devel] domU crashed when LTP was running
Date: Fri, 25 Jul 2008 17:24:47 +0900
@@ -262,7 +262,7 @@
{
if (ia64_boot_param-fpswa)
/* FPSWA fixup: make the interface pointer a virtual address */
- fpswa_interface = __va(ia64_boot_param-fpswa);
+ fpswa_interface = __va_efi(ia64_boot_param-fpswa);
else
printk(No FPSWA supported.\n);
}
Why is __va_efi() necessary? This changes caused that dom0 hung up.
Without it, dom0 booted and LTP completed on domU.
Thanks for testing.
You're right. __va_efi() is unnecessary.
[IA64] fix fpswa mapping which was broken by EFI mapping.
This patch fixes the following panic reported by Kusamura when xen
VMM tries to use fpswa.
With the EFI mapping patch, all the firmware call is done in
the dedicated address space.
fpswa is EFI driver so that the address space must be switched
before/after calling fpswa.
(XEN) $ PANIC in domain 2 (k6=0xf004f25e8000): ***
xen_handle_domain_access: exception table lookup failed,
iip=0xf4000408cc30,
addr=0xe004ffe62050, spinning...
(XEN) d 0xf4138080 domid 2
(XEN) vcpu 0xf004f25e8000 vcpu 0
(XEN)
(XEN) CPU 5
(XEN) psr : 121008226038 ifs : 8716 ip : [f4000408cc31]
(XEN) ip is at handle_fpu_swa+0x3c1/0x510
...
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r a7e68d48f625 xen/arch/ia64/xen/faults.c
--- a/xen/arch/ia64/xen/faults.cThu Jul 24 14:32:59 2008 +0900
+++ b/xen/arch/ia64/xen/faults.cMon Jul 28 12:40:47 2008 +0900
@@ -274,6 +274,7 @@
{
fp_state_t fp_state;
fpswa_ret_t ret;
+ XEN_EFI_RR_DECLARE(rr6, rr7);
if (!fpswa_interface)
return (fpswa_ret_t) {-1, 0, 0, 0};
@@ -299,8 +300,10 @@
* unsigned long*pifs,
* void *fp_state);
*/
+ XEN_EFI_RR_ENTER(rr6, rr7);
ret = (*fpswa_interface-fpswa) (fp_fault, bundle,
ipsr, fpsr, isr, pr, ifs, fp_state);
+ XEN_EFI_RR_LEAVE(rr6, rr7);
return ret;
}
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH][LINUX] Support timer vector IPIs in PVcode
Could please you point out url for the patch being accepted into xen-ia64 upstream? Thanks Luming -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isaku Yamahata Sent: 2008年7月28日 10:32 To: Alex Williamson Cc: xen-ia64-devel Subject: Re: [Xen-ia64-devel] [PATCH][LINUX] Support timer vector IPIs in PVcode On Thu, Jul 24, 2008 at 12:28:27PM -0600, Alex Williamson wrote: Upstream Linux recently added this change: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3463a93def55c309f3c0d0a8aaf216be3be42d64 Now, for a platform bug check, we issue an IPI for the IA64_TIMER_VECTOR and wait for it to show up in the IRR. Since a PV kernel doesn't support a timer IPI, this never happens. The fix is simply to tie this into xen_send_ipi() for this case. This doesn't actually happen on 2.6.18, but since vendors are backporting changes from upstream, I think it's good to have this in the reference tree. Thanks, Alex Add support for IA64_TIMER_VECTOR as a paravirtualized IPI target Necessary for the latest upstream Linux implementation of check_sal_cache_flush() 3463a93def55c309f3c0d0a8aaf216be3be42d64 Signed-off-by: Alex Williamson [EMAIL PROTECTED] Applied, thanks. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 4/5] kexec: fix /proc/iomem_machine
On Fri, Jul 25, 2008 at 01:46:03PM +0900, Isaku Yamahata wrote: On Thu, Jul 24, 2008 at 07:55:48PM +1000, Simon Horman wrote: I think that saved_max_pfn isn't entirely related to the problem that you are seeing. On Linux it is used in the second kernel after crash dump to deterimin the size of /proc/vmcore - that is to make it match the physical memory rather than the limited memory that the crash dump kernel runs in. As a crash dump kernel currently can't be a dom0 (or domU) kernel, I don't think that it is that important in the context of linux-xen. We could probably even eliminate it, but it seems better to leave it rather than add diferences to upstram linux. Also, while looking into your change I came across f4a570997e71b892805a1e71303d09c327af135f in upstream Linux. Again, it isn't needed in our code as our tree won't run as a crash dump kernel. But it might be good to align the code with what is in upstram Linux. Lastly, your change is already present in upstram Linux, I'm not sure how I managed to miss adding it to xen-Linux. Sorry about that :-( So I backported f4a570997e71b892805a1e71303d09c327af135f and e55fdf11f3029bcd41b1b9547ad9db12c27eea76. And here is the updated patch. [IA64] initialize /proc/iomem_machine properly when discontig mem. With CONFIG_DISCONTIGMEM enabled /proc/iomem_machine isn't initialized properly so that kexec failes because kexec-tools wrongly tries to use ia64 boot mem (or efi memmap area). This patch fixes /proc/iomem_machine. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] Acked-by: Simon Horman [EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [PATCH] backport f4a570997e71b892805a1e71303d09c327af135f (was Re: [Xen-ia64-devel] [PATCH 4/5] kexec: fix /proc/iomem_machine)
On Fri, Jul 25, 2008 at 01:47:02PM +0900, Isaku Yamahata wrote: [IA64] backport point saved_max_pfn to the max_pfn of the entire system backport Upstream Linux changeset f4a570997e71b892805a1e71303d09c327af135f Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] Acked-by: Simon Horman [EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [PATCH] backport e55fdf11f3029bcd41b1b9547ad9db12c27eea76 (was Re: [Xen-ia64-devel] [PATCH 4/5] kexec: fix /proc/iomem_machine)
On Fri, Jul 25, 2008 at 01:47:50PM +0900, Isaku Yamahata wrote: [IA64] backport Pick highest possible saved_max_pfn for crash_dump backport Upstream Linux changeset e55fdf11f3029bcd41b1b9547ad9db12c27eea76 Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] Acked-by: Simon Horman [EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH][LINUX] Support timer vector IPIs in PVcode
On Mon, 2008-07-28 at 11:44 +0800, Yu, Luming wrote: Could please you point out url for the patch being accepted into xen-ia64 upstream? I think this is what you're looking for: http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg?rev/c4b12c90de0e raw ascii: http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg?raw-rev/c4b12c90de0e 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
