[Xen-ia64-devel][PATCH] Accelerate some virtualization faults
Accelerate MOV_FROM_ITC and MOV_FROM_RR virtualization faults, More will be added. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony accelerate_some_virtualization_fault.patch Description: accelerate_some_virtualization_fault.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] create page table for virtual frame table
Hi,
I was so bad.
I should not use p?d_populate() functions to create the page table for
virtual frametable. It should be independent of domain's page table
structure. p?d_populate() are also used for domain's page table.
Currently page table for virtual frametable consists of 3-level
table. And the domain's page table is also. But I think 2-level might
be enough for virtual frametable. It should be configurable without any
concern for domain's structure. Once I had a plan to tune it up.
To aboid the confusion, I wrote an attached patch.
Isaku Yamahata writes:
#ifdef CONFIG_VIRTUAL_FRAME_TABLE
-shr r22=r16,56 // Test for the address of virtual frame_table
+shr.u r22=r16,56// Test for the address of virtual frame_table
;;
- cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22
+cmp.eq p8,p0=(VIRT_FRAME_TABLE_ADDR56),r22
(p8) br.cond.sptk frametable_miss ;;
#endif
That was a dirty hack.
Unfortunately, 'cmp' instruction can't handle such a immediate value(0xf3).
When the above patch is applied, The assembler complains:
ivt.S:547: Error: Operand 3 of `cmp.eq' should be an 8-bit integer (-128-127)
Thanks,
Kouya
Signed-off-by: Kouya SHIMURA [EMAIL PROTECTED]
xenmem.patch
Description: Binary data
Isaku Yamahata writes:
Hi.
As Jes explained, p?d_populate() requires virtual address for third argument.
So alloc_dir_page() should return virtual address.
On the otherhand __pa(__pa(va)) == __pa(va) because __pa() masks high 3bits
instead of __pa(va) = va - PAGE_OFFSET. Thus the current alloc_dir_page()
creates correct frame tables fortunately.
However alloc_dir_page() should be fixed, I think.
About ivt.S part. You might have missed that shr is signed extended shift.
Probably the following is more readable.
#ifdef CONFIG_VIRTUAL_FRAME_TABLE
-shr r22=r16,56 // Test for the address of virtual frame_table
+shr.u r22=r16,56// Test for the address of virtual frame_table
;;
- cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22
+cmp.eq p8,p0=(VIRT_FRAME_TABLE_ADDR56),r22
(p8) br.cond.sptk frametable_miss ;;
#endif
thanks.
On Thu, Sep 21, 2006 at 01:26:57PM +0200, Jes Sorensen wrote:
Kouya SHIMURA wrote:
Hi Jes,
I wrote the patch corresponding to discontig. You are wrong.
alloc_dir_page() must return a physical address because the page table
walker for frame_table runs under off-state of data-address-translation.
(i.e. psr.dt=0)
p*d_populate() functions never be called while handling TLB miss to
frame_table. The page table walker for frame_table is written in
assembler in xen/arch/ia64/xen/ivt.S. See the code between
'GLOBAL_ENTRY(frametable_miss)' and 'END(frametable_miss)'
Hi Kouya,
I am not talking about during the TLB miss but during the creation
of the tables. I changed the code in ivt.S to make sure what was
happening was explicit, ie. if we are trying to resolve things in the
VIRT_FRAME_TABLE_ADDR space, then the test I put into ivt.S should be
identical to your original code, but I cannot boot with your code, it
MCA's because frametable_miss is never called since we are comparing for
the wrong address.
Please take a look at this code:
arch/ia64/xen/xenmem.c:
static int
create_frametable_page_table (u64 start, u64 end, void *arg)
{
...
[snip]
...
if (pud_none(*pud))
pud_populate(NULL, pud, alloc_dir_page());
pmd = pmd_offset(pud, address);
if (pmd_none(*pmd))
pmd_populate_kernel(NULL, pmd,
alloc_dir_page());
pte = pte_offset_kernel(pmd, address);
Then in include/asm-ia64/linux-xen/asm/pgalloc.h you have this:
static inline void
pud_populate(struct mm_struct *mm, pud_t * pud_entry, pmd_t * pmd)
{
pud_val(*pud_entry) = __pa(pmd);
}
and
static inline void
pmd_populate_kernel(struct mm_struct *mm, pmd_t * pmd_entry, pte_t * pte)
{
pmd_val(*pmd_entry) = __pa(pte);
}
In other words, if alloc_dir_page() returns a physical address as it
did before, you end up doing __pa() on the physical address which
just cannot be correct.
My guess is that we were in fact doing a __pa() on the physical address
and the compare in ivt.S somehow was made to look at this address
instead of what it was pretending to do.
I'd like to be proven wrong though, but without this patch Xen on SN2
only gets to an MCA at the moment it tries to initialize the page table.
You'd better have a look at the thread below:
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-04/msg00014.html
I'll take a look.
Cheers,
Jes
Thanks,
Kouya
Jes Sorensen writes:
Hi,
Re: [Xen-ia64-devel] [patch] alloc_page_dir() should return a virtual address
Isaku == Isaku Yamahata [EMAIL PROTECTED] writes: Isaku Hi. As Jes explained, p?d_populate() requires virtual address Isaku for third argument. So alloc_dir_page() should return virtual Isaku address. On the otherhand __pa(__pa(va)) == __pa(va) because Isaku __pa() masks high 3bits instead of __pa(va) = va - Isaku PAGE_OFFSET. Thus the current alloc_dir_page() creates correct Isaku frame tables fortunately. However alloc_dir_page() should be Isaku fixed, I think. You are right, but somehow this made a difference for me on SN2, I wonder if the Linux version could have gotten pulled in somehow. I might look at the CPP output to be sure. Isaku About ivt.S part. You might have missed that shr is signed Isaku extended shift. Probably the following is more readable. Isaku #ifdef CONFIG_VIRTUAL_FRAME_TABLE - shr r22=r16,56 // Test for Isaku the address of virtual frame_table + shr.u r22=r16,56 // Test Isaku for the address of virtual frame_table ;; - cmp.eq Isaku p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22 + cmp.eq Isaku p8,p0=(VIRT_FRAME_TABLE_ADDR56),r22 (p8) br.cond.sptk Isaku frametable_miss ;; #endif I tried this but hit the obvious assembly error that Kouya also reported in the follow-up posting. I change it to the code I posted to make sure it was explicit and there was no doubt it couldn't fail. Best regards, Jes ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH]Complete fpswa handler retry mechanism
When handling fpswa fault, Xen needs to fetch opcode, it may fail. This patch finishes retry mechanism. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony fpswa_retry.patch Description: fpswa_retry.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
On Fri, Sep 22, 2006 at 01:50:34PM +0800, Xu, Anthony wrote: 1) 2 cases failed because can not allocate memory issue. This may be caused by failure of hypercall. Hypercal fails because this hypercall use pointer to pass parameter. But in XEN/IA64, copy_from/to_user don't guarantee to work. This is a big potential issue on XEN/IA64. In XEN/PPC, seems they use guest physical pointer to resolve this issue. What's your opinion about this? I think xencomm is the way to go. If Tristan ceases pushing it, we, VA Linux, are willing to take over it. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
-Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 17:09 To: Xu, Anthony Cc: You, Yongkang; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460 On Fri, Sep 22, 2006 at 01:50:34PM +0800, Xu, Anthony wrote: 1) 2 cases failed because can not allocate memory issue. This may be caused by failure of hypercall. Hypercal fails because this hypercall use pointer to pass parameter. But in XEN/IA64, copy_from/to_user don't guarantee to work. This is a big potential issue on XEN/IA64. In XEN/PPC, seems they use guest physical pointer to resolve this issue. What's your opinion about this? I think xencomm is the way to go. If Tristan ceases pushing it, we, VA Linux, are willing to take over it. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 17:09 I think xencomm is the way to go. If Tristan ceases pushing it, we, VA Linux, are willing to take over it. -- I guess Tristan ceased doing that. That would be great that VA linux can do that. Thanks, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Réf. : RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
Anthony and Isaku, I need to talk with Tristan on Monday (when he is back from vacation) about that. I think he still has a few changes almost ready to be sent in this area. Jean-Paul Xu, Anthony [EMAIL PROTECTED] Envoyé par : [EMAIL PROTECTED] 22/09/2006 11:13 Pour :Isaku Yamahata [EMAIL PROTECTED] cc :xen-ia64-devel@lists.xensource.com Objet :RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460 From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 17:09 I think xencomm is the way to go. If Tristan ceases pushing it, we, VA Linux, are willing to take over it. -- I guess Tristan ceased doing that. That would be great that VA linux can do that. Thanks, Anthony ___ 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
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) I don't mind asking RH to statically link the modules if there is good reason. However I don't understand why it is needed. 512M is a lot of memory! How can it be filled to the extent that the blkbk/netbk modules won't load? What are their requirements? Please see the following error message. FATAL: Error inserting blkbk (/lib/modules/2.6.17-1.2566.fc6xen/kernel/drivers/xen/ blkback/blkbk.ko): Cannot allocate memory modprobe: page allocation failure. order:8, mode:0xd0 blkbk.ko request order8 pages in blkif_init(). order8 pages is very big. page_alloc() probably fail when it is requested order8 pages, because page_alloc() must return contiguos pages. Especially after boot and terminate some processes, page_alloc() is hard to allocate order8 pages. So when dom0_mem=1G, page_allo() is easier to allocate them than dom0_mem=512M. And when statically linked modules, page_alloc() is the easest to allocate them. I think implementation of blk/netbk.ko is not good. But I think statically linked modules is the best solution in your solutions. And I think this issue is happened in the case of not only ia64, but also x86. (In the case of x86, default size of dom0_mem is physcal memory size. So this issue is hard to be happened.) Please commets. FYI https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202971 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
On 9/22/06, Xu, Anthony [EMAIL PROTECTED] wrote: From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 17:09 I think xencomm is the way to go. If Tristan ceases pushing it, we, VA Linux, are willing to take over it. -- I guess Tristan ceased doing that. That would be great that VA linux can do that. I will give it a try. My current knowledge about xencomm is kind of limited, so if you have any suggestions please let me know! Thanks, / magnus ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
This thread should be helpful. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-08/msg00285.html -Anthony -Original Message- From: Magnus Damm [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 17:40 To: Xu, Anthony Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com; Magnus Damm Subject: Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460 On 9/22/06, Xu, Anthony [EMAIL PROTECTED] wrote: From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 17:09 I think xencomm is the way to go. If Tristan ceases pushing it, we, VA Linux, are willing to take over it. -- I guess Tristan ceased doing that. That would be great that VA linux can do that. I will give it a try. My current knowledge about xencomm is kind of limited, so if you have any suggestions please let me know! Thanks, / magnus ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] create page table for virtual frame table
Kouya == Kouya SHIMURA [EMAIL PROTECTED] writes: Kouya Hi, I was so bad. Kouya I should not use p?d_populate() functions to create the page Kouya table for virtual frametable. It should be independent of Kouya domain's page table structure. p?d_populate() are also used for Kouya domain's page table. :-) Kouya Currently page table for virtual frametable consists of 3-level Kouya table. And the domain's page table is also. But I think 2-level Kouya might be enough for virtual frametable. It should be Kouya configurable without any concern for domain's structure. Once I Kouya had a plan to tune it up. Kouya To aboid the confusion, I wrote an attached patch. I tried your patch and it doesn't seem to make things worse here, but I noticed we use far less memory for the page tables so thats probably a good thing. Btw. for this part: #ifdef CONFIG_VIRTUAL_FRAME_TABLE -shr r22=r16,56 // Test for the address of virtual frame_table +shr.u r22=r16,56// Test for the address of virtual frame_table then if I make this change in my tree, the old compare works for me. I am somehow still worse off than I was yesterday in terms of how far I get, no idea why at this point. Cheers, Jes ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi Akio, Sorry for response late. It is very detailed instructions. :) I found my initrd doesn't preload xenblk.ko. Then it failed to create root device. Now I can create xenU too with your guide. Thank you so much. But did you notice xenU booting is a little slow? Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 13:06 To: You, Yongkang; Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com; Akio Takebe Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi, Yongkang and all I can boot up domU by using my special initrd without vif. I think mkinitrd of fc6 make initrd by using dom0 infomation. (for example dom0's /etc/fstab, dom0's pci infomaition. ) So when xm boot domU, domU kernel don't use bootparmeter of domU. The below is a recipe of making my special inird 1. copy initrd # mkdir tmp # cp /boot/efi/efi/redhat/initrd-2.6.18-1.2679.fc6xenU.img tmp/ 2. expand inird # cd tmp # gzip -cd ../initrd-2.6.18-1.2679.fc6xenU.img |cpio -id 3. modify init in initrd # vi init insmod /lib/ohci-hcd.ko echo Loading ehci-hcd.ko module insmod /lib/ehci-hcd.ko mount -t usbfs /proc/bus/usb /proc/bus/usb echo Loading jbd.ko module insmod /lib/jbd.ko echo Loading ext3.ko module insmod /lib/ext3.ko #echo Loading scsi_mod.ko modulecomment out #insmod /lib/scsi_mod.ko comment out #echo Loading sd_mod.ko module comment out #insmod /lib/sd_mod.kocomment out #echo Loading scsi_transport_spi.ko module comment out #insmod /lib/scsi_transport_spi.kocomment out #echo Loading mptbase.ko module comment out #insmod /lib/mptbase.ko comment out #echo Loading mptscsih.ko modulecomment out #insmod /lib/mptscsih.ko comment out #echo Loading mptspi.ko module comment out #insmod /lib/mptspi.kocomment out echo Loading xenblk.ko module insmod /lib/xenblk.ko mkblkdevs #resume LABEL=SWAP-sda3 comment out echo Creating root device. mkrootdev -t ext3 -o defaults,ro sda1 change device to sda1 echo Mounting root filesystem. mount /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot 4. make new initrd # find . -print | cpio --quiet -c -o | gzip -9 ../initrd-new.img 5. my domU configuration kernel = /boot/efi/efi/redhat/vmlinuz-2.6.18-1.2679.fc6xen ramdisk = /xen/initrd-new.img memory = 1024 name = fc6.DomU #vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] root = /dev/sda1 ro extra = 4 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe selinux=0 rhgb 6. etc 6.1. copy modlues into domU image file # mount -o loop domU.img /mnt # cp -a /lib/modules/2.6.18-1.2679.fc6xen/ /mnt/lib/modules/ 6.2. disable selinux # vi /etc/sysconfig/selinux SELINUX=disabled change enforcing to disabled 6.3. modify /etc/fstab in domU.img /dev/sda1 / ext3defaults1 1 devpts/dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults0 0 proc /proc procdefaults0 0 sysfs /sys sysfs defaults0 0 But I cannot use network on domU. I'll check the src.rpm of kernel-xen. Best Regards, Akio Takebe Hi Akio, Sorry for response late. I just tried with the config you provide (I changed xenU modprobe.conf and fstab). But unfortunately it still couldn't work. XenU booting still report can not find filesystem /dev/root/ and kernel panic. Well, after add ide0=noprobe etc. xenU won't complain to check hda, hdb etc. again. Thanks for this information. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006ト・ヤツ21ネユ 10:18 To: Akio Takebe; You, Yongkang; Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi, Yongkang I have a small mistake. Please try the following configuration. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] this root = /dev/sda1 ro this extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe --- -this Best Regards, Akio Takebe Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of
[Xen-ia64-devel] [PATCH 0/12]MCA handler support for Xen/ia64 TAKE 2
Hi, all The following patches are improvement and cleanup patches of the MCA support for xen/ia64 we've posted. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00034.html We have already tested not only MCA uncorrectable error handler but also corrected error(CMC/CPE) handlers. We added a improvement to save the MCA error record for logging by salinfod after reboot. At the boot time, Xen queues MCA error log, and salinfod on Dom0 gets the error log and save it. And several bug fixes and cleanups are also included in these patches. We would appreciate any comments. Thanks, You, Kan, and KAZ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 1/12]MCA handler support for Xen/ia64 TAKE 2
[1/12] patch for MCA handler.[mca-mca.patch]
Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/linux-xen/mca.c
--- a/xen/arch/ia64/linux-xen/mca.c Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/linux-xen/mca.c Fri Sep 22 09:26:49 2006 +0900
@@ -80,6 +80,9 @@
#ifdef XEN
#include xen/symbols.h
#include xen/mm.h
+#include xen/event.h
+#include xen/softirq.h
+#include asm/xenmca.h
#endif
#if defined(IA64_MCA_DEBUG_INFO)
@@ -107,18 +110,25 @@ unsigned long __per_cpu_mca[NR_CPUS];
/* In mca_asm.S */
extern voidia64_monarch_init_handler (void);
extern voidia64_slave_init_handler (void);
+#ifdef XEN
+extern void setup_vector (unsigned int vec, struct irqaction *action);
+#endif
static ia64_mc_info_t ia64_mc_info;
-#ifndef XEN
#define MAX_CPE_POLL_INTERVAL (15*60*HZ) /* 15 minutes */
#define MIN_CPE_POLL_INTERVAL (2*60*HZ) /* 2 minutes */
#define CMC_POLL_INTERVAL (1*60*HZ) /* 1 minute */
#define CPE_HISTORY_LENGTH5
#define CMC_HISTORY_LENGTH5
+#ifndefXEN
static struct timer_list cpe_poll_timer;
static struct timer_list cmc_poll_timer;
+#else /* XEN */
+static struct timer cpe_poll_timer;
+static struct timer cmc_poll_timer;
+#endif
/*
* This variable tells whether we are currently in polling mode.
* Start with this in the wrong state so we won't play w/ timers
@@ -135,11 +145,9 @@ static int cpe_poll_enabled = 1;
static int cpe_poll_enabled = 1;
extern void salinfo_log_wakeup(int type, u8 *buffer, u64 size, int irqsafe);
-#endif /* !XEN */
static int mca_init;
-#ifndef XEN
/*
* IA64_MCA log support
*/
@@ -156,11 +164,24 @@ typedef struct ia64_state_log_s
static ia64_state_log_t ia64_state_log[IA64_MAX_LOG_TYPES];
+#ifndefXEN
#define IA64_LOG_ALLOCATE(it, size) \
{ia64_state_log[it].isl_log[IA64_LOG_CURR_INDEX(it)] = \
(ia64_err_rec_t *)alloc_bootmem(size); \
ia64_state_log[it].isl_log[IA64_LOG_NEXT_INDEX(it)] = \
(ia64_err_rec_t *)alloc_bootmem(size);}
+#else /* XEN */
+#define IA64_LOG_ALLOCATE(it, size) \
+ do { \
+ unsigned int pageorder; \
+ pageorder = get_order_from_bytes(sizeof(struct ia64_mca_cpu));
\
+ ia64_state_log[it].isl_log[IA64_LOG_CURR_INDEX(it)] = \
+ (ia64_err_rec_t *)alloc_xenheap_pages(pageorder); \
+ ia64_state_log[it].isl_log[IA64_LOG_NEXT_INDEX(it)] = \
+ (ia64_err_rec_t *)alloc_xenheap_pages(pageorder); \
+ } while(0)
+#endif /* XEN */
+
#define IA64_LOG_LOCK_INIT(it) spin_lock_init(ia64_state_log[it].isl_lock)
#define IA64_LOG_LOCK(it) spin_lock_irqsave(ia64_state_log[it].isl_lock,
s)
#define IA64_LOG_UNLOCK(it)
spin_unlock_irqrestore(ia64_state_log[it].isl_lock,s)
@@ -175,6 +196,11 @@ static ia64_state_log_t ia64_state_log[I
#define IA64_LOG_CURR_BUFFER(it) (void
*)((ia64_state_log[it].isl_log[IA64_LOG_CURR_INDEX(it)]))
#define IA64_LOG_COUNT(it) ia64_state_log[it].isl_count
+#ifdef XEN
+struct list_head sal_queue[IA64_MAX_LOG_TYPES];
+DEFINE_SPINLOCK(sal_queue_lock);
+#endif /* XEN */
+
/*
* ia64_log_init
* Reset the OS ia64 log buffer
@@ -201,6 +227,7 @@ ia64_log_init(int sal_info_type)
memset(IA64_LOG_NEXT_BUFFER(sal_info_type), 0, max_size);
}
+#ifndef XEN
/*
* ia64_log_get
*
@@ -276,15 +303,151 @@ ia64_mca_log_sal_error_record(int sal_in
if (rh-severity == sal_log_severity_corrected)
ia64_sal_clear_state_info(sal_info_type);
}
+#else /* XEN */
+/*
+ * ia64_log_queue
+ *
+ * Get the current MCA log from SAL and copy it into the OS log buffer.
+ *
+ * Inputs : info_type (SAL_INFO_TYPE_{MCA,INIT,CMC,CPE})
+ * Outputs : size(total record length)
+ * *buffer (ptr to error record)
+ *
+ */
+static u64
+ia64_log_queue(int sal_info_type, int virq)
+{
+ sal_log_record_header_t *log_buffer;
+ u64 total_len = 0;
+ int s;
+ sal_queue_entry_t *e;
+ unsigned long flags;
+
+ IA64_LOG_LOCK(sal_info_type);
+
+ /* Get the process state information */
+ log_buffer = IA64_LOG_NEXT_BUFFER(sal_info_type);
+
+ total_len = ia64_sal_get_state_info(sal_info_type, (u64 *)log_buffer);
+
+ if (total_len) {
+ int queue_type;
+
+ spin_lock_irqsave(sal_queue_lock, flags);
+
+ if (sal_info_type == SAL_INFO_TYPE_MCA
+ virq == VIRQ_MCA_CMC)
+ queue_type = SAL_INFO_TYPE_CMC;
+ else
+ queue_type = sal_info_type;
+
+ e = xmalloc(sal_queue_entry_t);
+ e-cpuid = smp_processor_id();
+
[Xen-ia64-devel] [PATCH 4/12]MCA handler support for Xen/ia64 TAKE 2
[4/12] Add binding of virq/ipi to irq.[mca-irq_ia64.patch]
Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Tue Sep 12 11:43:22
2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Fri Sep 22 09:26:49
2006 +0900
@@ -241,9 +241,15 @@ static DEFINE_PER_CPU(int, timer_irq) =
static DEFINE_PER_CPU(int, timer_irq) = -1;
static DEFINE_PER_CPU(int, ipi_irq) = -1;
static DEFINE_PER_CPU(int, resched_irq) = -1;
+static DEFINE_PER_CPU(int, cmc_irq) = -1;
+static DEFINE_PER_CPU(int, cmcp_irq) = -1;
+static DEFINE_PER_CPU(int, cpep_irq) = -1;
static char timer_name[NR_CPUS][15];
static char ipi_name[NR_CPUS][15];
static char resched_name[NR_CPUS][15];
+static char cmc_name[NR_CPUS][15];
+static char cmcp_name[NR_CPUS][15];
+static char cpep_name[NR_CPUS][15];
struct saved_irq {
unsigned int irq;
@@ -323,6 +329,33 @@ xen_register_percpu_irq (unsigned int ir
break;
case IA64_SPURIOUS_INT_VECTOR:
break;
+ case IA64_CMC_VECTOR:
+ sprintf(cmc_name[cpu], %s%d, action-name, cpu);
+ ret = bind_virq_to_irqhandler(VIRQ_MCA_CMC, cpu,
+ action-handler, action-flags,
+ cmc_name[cpu], action-dev_id);
+ per_cpu(cmc_irq,cpu) = ret;
+ printk(KERN_INFO register VIRQ_MCA_CMC (%s) to xen irq
(%d)\n, cmc_name[cpu], ret);
+ break;
+ case IA64_CMCP_VECTOR:
+ sprintf(cmcp_name[cpu], %s%d, action-name, cpu);
+ ret = bind_ipi_to_irqhandler(CMCP_VECTOR, cpu,
+ action-handler, action-flags,
+ cmcp_name[cpu], action-dev_id);
+ per_cpu(cmcp_irq,cpu) = ret;
+ printk(KERN_INFO register CMCP_VECTOR (%s) to xen irq
(%d)\n, cmcp_name[cpu], ret);
+ break;
+ case IA64_CPEP_VECTOR:
+ sprintf(cpep_name[cpu], %s%d, action-name, cpu);
+ ret = bind_ipi_to_irqhandler(CPEP_VECTOR, cpu,
+ action-handler, action-flags,
+ cpep_name[cpu], action-dev_id);
+ per_cpu(cpep_irq,cpu) = ret;
+ printk(KERN_INFO register CPEP_VECTOR (%s) to xen irq
(%d)\n, cpep_name[cpu], ret);
+ break;
+ case IA64_CPE_VECTOR:
+ printk(KERN_WARNING register IA64_CPE_VECTOR
IGNORED\n);
+ break;
default:
printk(KERN_WARNING Percpu irq %d is unsupported by
xen!\n, irq);
break;
@@ -373,6 +406,18 @@ unbind_evtchn_callback(struct notifier_b
if (action == CPU_DEAD) {
/* Unregister evtchn. */
+ if (per_cpu(cpep_irq,cpu) = 0) {
+ unbind_from_irqhandler (per_cpu(cpep_irq, cpu), NULL);
+ per_cpu(cpep_irq, cpu) = -1;
+ }
+ if (per_cpu(cmcp_irq,cpu) = 0) {
+ unbind_from_irqhandler (per_cpu(cmcp_irq, cpu), NULL);
+ per_cpu(cmcp_irq, cpu) = -1;
+ }
+ if (per_cpu(cmc_irq,cpu) = 0) {
+ unbind_from_irqhandler (per_cpu(cmc_irq, cpu), NULL);
+ per_cpu(cmc_irq, cpu) = -1;
+ }
if (per_cpu(ipi_irq,cpu) = 0) {
unbind_from_irqhandler (per_cpu(ipi_irq, cpu), NULL);
per_cpu(ipi_irq, cpu) = -1;
@@ -503,6 +548,12 @@ ia64_send_ipi (int cpu, int vector, int
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_WARNINGUnsupported IPI type 0x%x\n,
vector);
irq = 0;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 2/12]MCA handler support for Xen/ia64 TAKE 2
[2/12] Add percpu data physical addr mca_asm.S [mca-mca_asm.patch]
Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/linux-xen/mca_asm.S
--- a/xen/arch/ia64/linux-xen/mca_asm.S Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/linux-xen/mca_asm.S Fri Sep 22 09:26:49 2006 +0900
@@ -24,6 +24,9 @@
#include asm/processor.h
#include asm/mca_asm.h
#include asm/mca.h
+#ifdef XEN
+#include asm/vhpt.h
+#endif /* XEN */
/*
* When we get a machine check, the kernel stack pointer is no longer
@@ -50,8 +53,7 @@
*/
#ifdef XEN
#define SAL_TO_OS_MCA_HANDOFF_STATE_SAVE(_tmp) \
- movl_tmp=THIS_CPU(ia64_sal_to_os_handoff_state_addr);; \
- tpa _tmp=_tmp;; \
+ GET_THIS_PADDR(_tmp, ia64_sal_to_os_handoff_state_addr);; \
ld8 _tmp=[_tmp];; \
st8 [_tmp]=r1,0x08;;\
st8 [_tmp]=r8,0x08;;\
@@ -72,6 +74,7 @@
st8 [_tmp]=r12,0x08;; \
st8 [_tmp]=r17,0x08;; \
st8 [_tmp]=r18,0x08
+#endif /* XEN */
/*
* OS_MCA_TO_SAL_HANDOFF_STATE (SAL 3.0 spec)
@@ -101,6 +104,24 @@
* imots_sal_check_ra=Return address to location within SAL_CHECK
*
*/
+#ifdef XEN
+#define COLD_BOOT_HANDOFF_STATE(sal_to_os_handoff,os_to_sal_handoff,tmp)\
+ movltmp=IA64_MCA_COLD_BOOT; \
+ GET_THIS_PADDR(r2,ia64_sal_to_os_handoff_state_addr);; \
+ ld8 sal_to_os_handoff=[sal_to_os_handoff];; \
+ movlos_to_sal_handoff=ia64_os_to_sal_handoff_state;;\
+ dep os_to_sal_handoff = 0, os_to_sal_handoff, 60, 4;; \
+ /*DATA_VA_TO_PA(os_to_sal_handoff);;*/ \
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ ld8 tmp=[sal_to_os_handoff],48;;\
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ movltmp=IA64_MCA_SAME_CONTEXT;; \
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ ld8 tmp=[sal_to_os_handoff],-8;;\
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ ld8 tmp=[sal_to_os_handoff];; \
+ st8 [os_to_sal_handoff]=tmp;;
+#else /* XEN */
#define COLD_BOOT_HANDOFF_STATE(sal_to_os_handoff,os_to_sal_handoff,tmp)\
movltmp=IA64_MCA_COLD_BOOT; \
movlsal_to_os_handoff=__pa(ia64_sal_to_os_handoff_state); \
@@ -114,13 +135,13 @@
st8 [os_to_sal_handoff]=tmp,8;; \
ld8 tmp=[sal_to_os_handoff];; \
st8 [os_to_sal_handoff]=tmp;;
+#endif /* XEN */
#define GET_IA64_MCA_DATA(reg) \
GET_THIS_PADDR(reg, ia64_mca_data) \
;; \
ld8 reg=[reg]
-#endif /* XEN */
.global ia64_os_mca_dispatch
.global ia64_os_mca_dispatch_end
#ifndef XEN
@@ -132,7 +153,40 @@
.text
.align 16
-#ifndef XEN
+#ifdef XEN
+/*
+ * void set_per_cpu_data(void)
+ * {
+ * int i;
+ * for (i = 0; i 64; i++) {
+ * if (ia64_mca_tlb_list[i].cr_lid == ia64_getreg(_IA64_REG_CR_LID)) {
+ * ia64_set_kr(IA64_KR_PER_CPU_DATA, ia64_mca_tlb_list[i].percpu_paddr);
+ * return;
+ * }
+ * }
+ * while(1); // Endless loop on error
+ * }
+ */
+#defineSET_PER_CPU_DATA() \
+ LOAD_PHYSICAL(p0,r2,ia64_mca_tlb_list);;\
+ mov r7 = r0;\
+ mov r6 = r0;; \
+ adds r3 = IA64_MCA_PERCPU_OFFSET, r2; \
+1: add r4 = r6, r2;\
+ mov r5=cr.lid;; \
+ adds r7 = 1, r7;\
+ ld8 r4 = [r4];; \
+ cmp.ne p6, p7 = r5, r4; \
+ cmp4.lt p8, p9 = NR_CPUS-1, r7; \
+(p7) br.cond.dpnt 3f;\
+ adds r6 = 16, r6; \
+(p9) br.cond.sptk 1b;\
+2: br 2b;; /* Endless loop on error*/ \
+3: add r4 = r6, r3;; \
+ ld8 r4 = [r4];; \
+ mov ar.k3=r4
+#endif
[Xen-ia64-devel] [PATCH 3/12]MCA handler support for Xen/ia64 TAKE 2
[3/12] Fix GET_THIS_PADDR and define log queue struct.[mca-header.patch]
Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/include/asm-ia64/xenmca.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/include/asm-ia64/xenmca.h Fri Sep 22 09:28:04 2006 +0900
@@ -0,0 +1,34 @@
+/*
+ * File: xenmca.h
+ * Purpose:Machine check handling specific defines for Xen
+ *
+ * Copyright (C) 2006 FUJITSU LTD. ([EMAIL PROTECTED])
+ */
+
+#ifndef _ASM_IA64_XENMCA_H
+#define _ASM_IA64_XENMCA_H
+
+#ifndef__ASSEMBLER__
+#include linux/list.h
+#include asm/sal.h
+
+typedef struct sal_queue_entry_t {
+ int cpuid;
+ int sal_info_type;
+ unsigned int vector;
+ unsigned int virq;
+ unsigned int length;
+ struct list_head list;
+} sal_queue_entry_t;
+
+extern struct list_head sal_queue[];
+
+struct ia64_mca_tlb_info {
+ u64 cr_lid;
+ u64 percpu_paddr;
+};
+
+extern struct ia64_mca_tlb_info ia64_mca_tlb_list[];
+#endif /* __ASSEMBLER__ */
+
+#endif /* _ASM_IA64_XENMCA_H */
diff -r 3e4fa8b5b245 xen/include/asm-ia64/linux-xen/asm/mca_asm.h
--- a/xen/include/asm-ia64/linux-xen/asm/mca_asm.h Tue Sep 12 11:43:22
2006 -0600
+++ b/xen/include/asm-ia64/linux-xen/asm/mca_asm.h Fri Sep 22 09:26:49
2006 +0900
@@ -59,8 +59,8 @@
#ifdef XEN
#define GET_THIS_PADDR(reg, var) \
- movlreg = THIS_CPU(var) \
- tpa reg = reg
+ mov reg = IA64_KR(PER_CPU_DATA);; \
+ addlreg = THIS_CPU(var) - PERCPU_ADDR, reg
#else
#define GET_THIS_PADDR(reg, var) \
mov reg = IA64_KR(PER_CPU_DATA);; \
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 5/12]MCA handler support for Xen/ia64 TAKE 2
[5/12] Define MCA interrupt vector.[mca-irq.patch]
Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 linux-2.6-xen-sparse/include/asm-ia64/irq.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/irq.h Tue Sep 12 11:43:22
2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/irq.h Fri Sep 22 09:26:49
2006 +0900
@@ -42,7 +42,9 @@
#define RESCHEDULE_VECTOR 0
#define IPI_VECTOR 1
-#define NR_IPIS2
+#define CMCP_VECTOR2
+#define CPEP_VECTOR3
+#define NR_IPIS4
#endif /* CONFIG_XEN */
/*
diff -r 3e4fa8b5b245 xen/include/asm-ia64/event.h
--- a/xen/include/asm-ia64/event.h Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/include/asm-ia64/event.h Fri Sep 22 09:26:49 2006 +0900
@@ -70,6 +70,8 @@ static inline int arch_virq_is_global(in
switch ( virq )
{
case VIRQ_ITC:
+case VIRQ_MCA_CMC:
+case VIRQ_MCA_CPE:
rc = 0;
break;
default:
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 8/12]MCA handler support for Xen/ia64 TAKE 2
[8/12] smpboot support for MCA.[mca-smpboot.patch] Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED] diff -r 3e4fa8b5b245 xen/arch/ia64/linux-xen/smpboot.c --- a/xen/arch/ia64/linux-xen/smpboot.c Tue Sep 12 11:43:22 2006 -0600 +++ b/xen/arch/ia64/linux-xen/smpboot.c Fri Sep 22 09:26:49 2006 +0900 @@ -365,9 +365,7 @@ smp_callin (void) smp_setup_percpu_timer(); -#ifndef XEN ia64_mca_cmc_vector_setup();/* Setup vector on AP */ -#endif #ifdef CONFIG_PERFMON pfm_init_percpu(); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 7/12]MCA handler support for Xen/ia64 TAKE 2
[7/12] Add lid and percpu paddr table.[mca-mm_init.patch] Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED] diff -r 3e4fa8b5b245 xen/arch/ia64/xen/mm_init.c --- a/xen/arch/ia64/xen/mm_init.c Tue Sep 12 11:43:22 2006 -0600 +++ b/xen/arch/ia64/xen/mm_init.c Fri Sep 22 09:26:49 2006 +0900 @@ -10,6 +10,11 @@ #include xen/sched.h #include asm/vhpt.h +#include asm/xenmca.h +#include asm/meminit.h +#include asm/page.h + +struct ia64_mca_tlb_info ia64_mca_tlb_list[NR_CPUS]; extern void ia64_tlb_init (void); @@ -105,7 +110,10 @@ ia64_mmu_init (void *my_cpu_data) ia64_mca_tlb_list[cpu].ptce_count[1] = local_cpu_data-ptce_count[1]; ia64_mca_tlb_list[cpu].ptce_stride[0] = local_cpu_data-ptce_stride[0]; ia64_mca_tlb_list[cpu].ptce_stride[1] = local_cpu_data-ptce_stride[1]; -#endif +#else /* XEN */ + ia64_mca_tlb_list[cpu].cr_lid = ia64_getreg(_IA64_REG_CR_LID); + ia64_mca_tlb_list[cpu].percpu_paddr = __pa(my_cpu_data); +#endif /* XEN */ } void ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 10/12]MCA handler support for Xen/ia64 TAKE 2
[10/12] Define VIRQs for MCA.[mca-arch-ia64.patch] Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED] diff -r 3e4fa8b5b245 xen/include/public/arch-ia64.h --- a/xen/include/public/arch-ia64.hTue Sep 12 11:43:22 2006 -0600 +++ b/xen/include/public/arch-ia64.hFri Sep 22 09:26:49 2006 +0900 @@ -39,6 +39,9 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); /* Arch specific VIRQs definition */ #define VIRQ_ITCVIRQ_ARCH_0 /* V. Virtual itc timer */ + +#defineVIRQ_MCA_CMC VIRQ_ARCH_1 /* MCA cmc interrupt */ +#define VIRQ_MCA_CPE VIRQ_ARCH_2 /* MCA cpe interrupt */ /* Maximum number of virtual CPUs in multi-processor guests. */ /* WARNING: before changing this, check that shared_info fits on a page */ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 6/12]MCA handler support for Xen/ia64 TAKE 2
[6/12] Add sal emulation.[mca-fw_emul.patch]
Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/fw_emul.c
--- a/xen/arch/ia64/xen/fw_emul.c Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/fw_emul.c Fri Sep 22 09:26:49 2006 +0900
@@ -23,6 +23,7 @@
#include linux/efi.h
#include asm/pal.h
#include asm/sal.h
+#include asm/xenmca.h
#include public/sched.h
#include hpsim_ssc.h
@@ -32,6 +33,52 @@
extern unsigned long running_on_sim;
+struct sal_mc_params {
+ u64 param_type;
+ u64 i_or_m;
+ u64 i_or_m_val;
+ u64 timeout;
+ u64 rz_always;
+} sal_mc_params[SAL_MC_PARAM_CPE_INT+1];
+
+struct sal_vectors {
+ u64 vector_type;
+ u64 handler_addr1;
+ u64 gp1;
+ u64 handler_len1;
+ u64 handler_addr2;
+ u64 gp2;
+ u64 handler_len2;
+} sal_vectors[SAL_VECTOR_OS_BOOT_RENDEZ+1];
+
+struct smp_call_args_t {
+ u64 type;
+ u64 ret;
+ void *data;
+};
+
+extern spinlock_t sal_queue_lock;
+
+#if defined(IA64_SAL_DEBUG_INFO)
+static const char * const rec_name[] = { MCA, INIT, CMC, CPE };
+
+# define IA64_SAL_DEBUG(fmt...)printk(sal_emulator: fmt)
+#else
+# define IA64_SAL_DEBUG(fmt...)
+#endif
+
+void get_state_info_on(void *data) {
+ struct smp_call_args_t *arg = data;
+
+ arg-ret = ia64_sal_get_state_info(arg-type, (u64 *)arg-data);
+}
+
+void clear_state_info_on(void *data) {
+ struct smp_call_args_t *arg = data;
+
+ arg-ret = ia64_sal_clear_state_info(arg-type);
+}
+
struct sal_ret_values
sal_emulator (long index, unsigned long in1, unsigned long in2,
unsigned long in3, unsigned long in4, unsigned long in5,
@@ -102,27 +149,204 @@ sal_emulator (long index, unsigned long
}
}
else
- printf(*** CALLED SAL_SET_VECTORS %lu. IGNORED...\n,
- in1);
+ {
+ if (in1 sizeof(sal_vectors)/sizeof(sal_vectors[0])-1)
+ BUG();
+ sal_vectors[in1].vector_type= in1;
+ sal_vectors[in1].handler_addr1 = in2;
+ sal_vectors[in1].gp1= in3;
+ sal_vectors[in1].handler_len1 = in4;
+ sal_vectors[in1].handler_addr2 = in5;
+ sal_vectors[in1].gp2= in6;
+ sal_vectors[in1].handler_len2 = in7;
+ }
break;
case SAL_GET_STATE_INFO:
- /* No more info. */
- status = -5;
- r9 = 0;
+ {
+ sal_queue_entry_t *e;
+ unsigned long flags;
+ int size = ia64_sal_get_state_info_size(in1);
+ static sal_log_record_header_t *record = NULL;
+
+ if (record == NULL) {
+ unsigned int pageorder;
+
+ pageorder = get_order_from_bytes(size);
+ record = (sal_log_record_header_t
*)alloc_xenheap_pages(pageorder);
+ }
+ memset(record, 0, size);
+
+ spin_lock_irqsave(sal_queue_lock, flags);
+ if (list_empty(sal_queue[in1])) {
+ sal_log_record_header_t header;
+
+ IA64_SAL_DEBUG(SAL_GET_STATE_INFO(%s)
+
no sal_queue entry found.\n, rec_name[in1]);
+ memset(header, 0, sizeof(header));
+ if (copy_to_user((void __user *)in3, header,
sizeof(header))) {
+ printk(sal_emulator:
SAL_GET_STATE_INFO
+can't copy
empty header to user: 0x%lx\n, in3);
+ }
+ status = -5;
+ r9 = 0;
+ spin_unlock_irqrestore(sal_queue_lock, flags);
+ break;
+ }
+ e = list_entry(sal_queue[in1].next, sal_queue_entry_t,
list);
+
+ if (e-cpuid == smp_processor_id()) {
+ if (in1 == e-sal_info_type) {
+ IA64_SAL_DEBUG(SAL_GET_STATE_INFO(%s)
+
on current CPU.\n, rec_name[in1]);
+ } else {
+ IA64_SAL_DEBUG(SAL_GET_STATE_INFO(%s
= %s)
+
[Xen-ia64-devel] [PATCH 9/12]MCA handler support for Xen/ia64 TAKE 2
[9/12] Add MCA offset entry.[mca-asm-offset.patch] Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED] diff -r 3e4fa8b5b245 xen/arch/ia64/asm-offsets.c --- a/xen/arch/ia64/asm-offsets.c Tue Sep 12 11:43:22 2006 -0600 +++ b/xen/arch/ia64/asm-offsets.c Fri Sep 22 09:26:49 2006 +0900 @@ -12,6 +12,7 @@ #include public/xen.h #include asm/tlb.h #include asm/regs.h +#include asm/xenmca.h #define task_struct vcpu @@ -217,4 +218,32 @@ void foo(void) DEFINE(FAST_HYPERPRIVOP_PERFC_OFS, offsetof (struct perfcounter, fast_hyperprivop)); DEFINE(FAST_REFLECT_PERFC_OFS, offsetof (struct perfcounter, fast_reflect)); #endif + + BLANK(); + DEFINE(IA64_CPUINFO_PTCE_BASE_OFFSET, + offsetof (struct cpuinfo_ia64, ptce_base)); + DEFINE(IA64_CPUINFO_PTCE_COUNT_OFFSET, + offsetof (struct cpuinfo_ia64, ptce_count)); + DEFINE(IA64_CPUINFO_PTCE_STRIDE_OFFSET, + offsetof (struct cpuinfo_ia64, ptce_stride)); + + BLANK(); + DEFINE(IA64_MCA_CPU_PROC_STATE_DUMP_OFFSET, + offsetof (struct ia64_mca_cpu, proc_state_dump)); + DEFINE(IA64_MCA_CPU_STACK_OFFSET, + offsetof (struct ia64_mca_cpu, stack)); + DEFINE(IA64_MCA_CPU_STACKFRAME_OFFSET, + offsetof (struct ia64_mca_cpu, stackframe)); + DEFINE(IA64_MCA_CPU_RBSTORE_OFFSET, + offsetof (struct ia64_mca_cpu, rbstore)); + + DEFINE(IA64_DOMAIN_SHARED_INFO_OFFSET, + offsetof (struct domain, shared_info)); + DEFINE(IA64_DOMAIN_SHARED_INFO_VA_OFFSET, + offsetof (struct domain, arch.shared_info_va)); + + BLANK(); + DEFINE(IA64_MCA_TLB_INFO_SIZE, sizeof (struct ia64_mca_tlb_info)); + DEFINE(IA64_MCA_PERCPU_OFFSET, + offsetof (struct ia64_mca_tlb_info, percpu_paddr)); } ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 12/12]MCA handler support for Xen/ia64 TAKE 2
[12/12] Fix conflicts of typedef of UINT64 and BOOLEAN.[mca-typedef.patch] Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED] diff -r 3e4fa8b5b245 xen/include/acpi/actypes.h --- a/xen/include/acpi/actypes.hTue Sep 12 11:43:22 2006 -0600 +++ b/xen/include/acpi/actypes.hFri Sep 22 09:26:49 2006 +0900 @@ -103,12 +103,18 @@ typedef COMPILER_DEPENDENT_UINT64 * 64-bit type definitions */ typedef unsigned char UINT8; +#ifndef__TYPEDEF_BOOLEAN__ +#define__TYPEDEF_BOOLEAN__ typedef unsigned char BOOLEAN; +#endif /* __TYPEDEF_BOOLEAN__ */ typedef unsigned short UINT16; typedef int INT32; typedef unsigned intUINT32; typedef COMPILER_DEPENDENT_INT64INT64; +#ifndef__TYPEDEF_UINT64__ +#define__TYPEDEF_UINT64__ typedef COMPILER_DEPENDENT_UINT64 UINT64; +#endif /* __TYPEDEF_UINT64__ */ /*! [End] no source code translation !*/ diff -r 3e4fa8b5b245 xen/include/asm-ia64/vcpu.h --- a/xen/include/asm-ia64/vcpu.h Tue Sep 12 11:43:22 2006 -0600 +++ b/xen/include/asm-ia64/vcpu.h Fri Sep 22 09:26:49 2006 +0900 @@ -10,9 +10,15 @@ #include asm/ia64_int.h #include xen/types.h #include public/xen.h +#ifndef__TYPEDEF_UINT64__ +#define__TYPEDEF_UINT64__ typedefunsigned long UINT64; +#endif /* __TYPEDEF_UINT64__ */ typedefunsigned int UINT; +#ifndef__TYPEDEF_BOOLEAN__ +#define__TYPEDEF_BOOLEAN__ typedefint BOOLEAN; +#endif /* __TYPEDEF_BOOLEAN__ */ struct vcpu; typedefstruct vcpu VCPU; typedef cpu_user_regs_t REGS; ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 11/12]MCA handler support for Xen/ia64 TAKE 2
[11/12] Add softirq handle for MCA.[mca-softirq.patch] Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED] diff -r 3e4fa8b5b245 xen/include/xen/softirq.h --- a/xen/include/xen/softirq.h Tue Sep 12 11:43:22 2006 -0600 +++ b/xen/include/xen/softirq.h Fri Sep 22 09:26:49 2006 +0900 @@ -10,7 +10,13 @@ #define PAGE_SCRUB_SOFTIRQ5 #define DOMAIN_SHUTDOWN_FINALISE_SOFTIRQ 6 #define TRACE_SOFTIRQ 7 +#ifdef __ia64__ +#define CMC_DISABLE_SOFTIRQ 8 +#define CMC_ENABLE_SOFTIRQ9 +#define NR_SOFTIRQS 10 +#else /* __ia64__ */ #define NR_SOFTIRQS 8 +#endif /* __ia64__ */ #ifndef __ASSEMBLY__ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang Hi Akio, Sorry for response late. It is very detailed instructions. :) I found my initrd doesn't preload xenblk.ko. Then it failed to create root device. Now I can create xenU too with your guide. Thank you so much. But did you notice xenU booting is a little slow? Yes, starting sendmail is very slow. I also suspected dom0/domU hanged up. :-) Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] sparsemem/discontig?
Hi Jes, I checked your old mail. I might figure out your problem. Xen/IPF assumes that the location of its kernel is starting at physical address 0x400. And its virtual address must be 0xf400. Xen uses __pa() macro everywhere to get a physical address of symbol which is declared inside kernel. But it seems that your Altix box doesn't have such a lower addressed physical memory. I guess that your kernel is located from 0x301400 to 0x301800. If so, __pa() macro doesn't work well and `Unimplemented Data Address fault' would happen. I'm not confident at all but please try modifying every value in xen/arch/ia64/xen.lds.s as follows: 0xf400 = 0xf0301400 Thanks, Kouya Jes Sorensen writes: Right now I am getting this output from Xen on a small Altix (4 nodes, 8 cpus, 6GB of RAM): (XEN) Init boot pages: 0x3003000120 - 0x301400. (XEN) Init boot pages: 0x301800 - 0x307bffc000. (XEN) Init boot pages: 0xb00300 - 0xb07c00. (XEN) Init boot pages: 0x1300300 - 0x1303c00. (XEN) Init boot pages: 0x1b00300 - 0x1b038ec5000. (XEN) Init boot pages: 0x1b039da8d20 - 0x1b03a3a4010. (XEN) Init boot pages: 0x1b03a3a4070 - 0x1b03a3a7fcd. (XEN) Init boot pages: 0x1b03a3a8010 - 0x1b03a42c010. (XEN) Init boot pages: 0x1b03a42cbe0 - 0x1b03a7fc000. (XEN) Init boot pages: 0x1b03b80 - 0x1b03bd64000. (XEN) Init boot pages: 0x1b03bda - 0x1b03be1. (XEN) Init boot pages: 0x1b03be8 - 0x1b03bea. I haven't checked yet whether the code receiving those tables does anything with it to round up to granule alignment etc. otherwise it could explain why the thing explodes for me. But what it does is that it takes forever to get to the point where it prints the total System RAM - in fact at first I thought the system had crashed and only because I once left it for several minutes did I end up seeing this output :( Jes ___ 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
[Xen-ia64-devel] [PATCH][RFC] New command: xm pcpu-list
Hi all, I would push a new command xm pcpu-list that reports physical CPU configuration. I suppose that Xen works on a machine where a lot of physical CPUs are installed. It is useful for users to know the configuration of physical CPUs so that they can allocate VCPUs efficiently. This command offers the means for it. I began this patch with ia64 machines. It is just because I have one. I would like to make this command work on x86 and powerpc machines. Unfortunately, I don't have any with dual-core and multi-thread features. I don't have much information on them either. I would appreciate if you give any help to make the command work on x86 and powerpc. Best regards, Kan cf. # xm pcpu-list PCPU Node Socket CoreThread State 0 00x001802 0 0 online 1 00x001803 0 0 online 2 00x001800 1 0 online 3 00x001801 1 0 online 4 00x001802 1 0 online 5 00x001803 1 0 online 6 00x001800 0 1 online 7 00x001801 0 1 online 8 00x001802 0 1 online 9 00x001803 0 1 online 10 00x001800 1 1 online 11 00x001801 1 1 online 12 00x001802 1 1 online 13 00x001803 1 1 online 14 00x001800 0 0 online 15 00x001801 0 0 online # xm info host : tiger154 release: 2.6.16.13-xen version: #1 SMP Fri Sep 22 11:28:14 JST 2006 machine: ia64 nr_cpus: 16 nr_nodes : 1 sockets_per_node : 4 cores_per_socket : 2 threads_per_core : 2 cpu_mhz: 1595 hw_caps: :::::::: total_memory : 8166 free_memory: 7586 xen_major : 3 xen_minor : 0 xen_extra : -unstable xen_caps : xen-3.0-ia64 hvm-3.0-ia64 xen_pagesize : 16384 platform_params: virt_start=0xe800 xen_changeset : Thu Sep 21 15:35:45 2006 -0600 11460: da942e577e5e cc_compiler: gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) cc_compile_by : root cc_compile_domain : cc_compile_date: Fri Sep 22 11:23:42 JST 2006 xend_config_format : 2 pcpu-list.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] pickled code
Isaku Yamahata wrote: Hi Jes. Your patch works for me. However I have two comments. - xen_heap_start xenheap_virt_start might be consistent compared to xenheap_phys_end. But this is only my preference. I'm not sure which is consistent for others. Hi Isaku, Glad it works, maybe we can convince Alex to apply it then :) I am not sure I understand what you mean about the heap_start unfortunately. - Probably this variable is a good candidate for __read_mostly. However Currently Xen/IA64 defines __read_mostly as nothing. So I think it's good time to support __read_mostly. Common codes utilize it. Sounds like a good idea. Thanks, Jes ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH][RFC] New command: xm pcpu-list
I would push a new command xm pcpu-list that reports physical CPU configuration. I suppose that Xen works on a machine where a lot of physical CPUs are installed. It is useful for users to know the configuration of physical CPUs so that they can allocate VCPUs efficiently. This command offers the means for it. I began this patch with ia64 machines. It is just because I have one. I would like to make this command work on x86 and powerpc machines. Unfortunately, I don't have any with dual-core and multi-thread features. I don't have much information on them either. I would appreciate if you give any help to make the command work on x86 and powerpc. The example you give below is a truly bizarre enumeration of CPUs. X86 does effectively enumerates [nodes][sockets][cores][threads] (in C terminology), hence on a hyperthreaded system PCPU 0 and 1 are in the same core. I think it would be good if ia64 followed suit. There was some discussion ages back about making it such that the tools would interpret hierarchical PCPU 'addressing' rather than just the PCPU number, i.e. you could refer to CPU 1.2.1.0 for the first hyperthread on the second core of the third socket of the second node. For systems that missed levels of the hierarchy e.g. single node, or no hyperthreads, the hierarchy could be collapsed in the obvious way. I'd still like to see this implemented. pcpu-list would then be less necessary, but you'd still want something like it to see which CPUs are online once we start to do physical CPU hotplug. Thanks, Ian Best regards, Kan cf. # xm pcpu-list PCPU Node Socket CoreThread State 0 00x001802 0 0 online 1 00x001803 0 0 online 2 00x001800 1 0 online 3 00x001801 1 0 online 4 00x001802 1 0 online 5 00x001803 1 0 online 6 00x001800 0 1 online 7 00x001801 0 1 online 8 00x001802 0 1 online 9 00x001803 0 1 online 10 00x001800 1 1 online 11 00x001801 1 1 online 12 00x001802 1 1 online 13 00x001803 1 1 online 14 00x001800 0 0 online 15 00x001801 0 0 online # xm info host : tiger154 release: 2.6.16.13-xen version: #1 SMP Fri Sep 22 11:28:14 JST 2006 machine: ia64 nr_cpus: 16 nr_nodes : 1 sockets_per_node : 4 cores_per_socket : 2 threads_per_core : 2 cpu_mhz: 1595 hw_caps: :::::::: total_memory : 8166 free_memory: 7586 xen_major : 3 xen_minor : 0 xen_extra : -unstable xen_caps : xen-3.0-ia64 hvm-3.0-ia64 xen_pagesize : 16384 platform_params: virt_start=0xe800 xen_changeset : Thu Sep 21 15:35:45 2006 -0600 11460: da942e577e5e cc_compiler: gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) cc_compile_by : root cc_compile_domain : cc_compile_date: Fri Sep 22 11:23:42 JST 2006 xend_config_format : 2 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
