Re: [Xen-ia64-devel] Re: PATCH: xencomm [2]
Le Dimanche 01 Octobre 2006 18:30, Alex Williamson a écrit : On Fri, 2006-09-29 at 16:50 +0200, Tristan Gingold wrote: thank you for heavy testing. I have updated the patch. These issues are fixed. I was able to do a local live migration. Hi Tristan, We're getting closer. UP domU save/restore works fine and I no longer see any of the unknown call warnings with VTi domains. However, trying to save a 2-way, 2GB domU consistently produces the crash below. Thanks, Thank. One day xencomm will be bug free :-) Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Memory problem with mini-os
Hi, after my vacation I switched from xen-ia64 change-set 11039 to 11635. And now I have a problem with my mini-os executing the efi/pal code (currently the getTime - function from efi). Every time the function gets called I get an trap 22 (Instruction access rights vector). The strange thing is that the trap also occurs if I don't do the mapping of the pal code. I inserted some trace messages in vcpu_itr_i() in xen to see all parameters. But it looks ok. For a test I removed the call of in ia64_itr() in efi_map_pal_code() in the linux code and nevertheless efi_gettimeofday() runs fine (linux as domU). It seems, there is another tlb entry for this page. I saw that the pal/efi stuff was reorganized in the new change-set. Can anybody give me a hint where to look in the memory handling or do some trace messages! I'm currently still not familiar enough with this stuff. Thanks. Dietmar. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Memory problem with mini-os
Le Lundi 02 Octobre 2006 09:35, Dietmar Hahn a écrit : Hi, after my vacation I switched from xen-ia64 change-set 11039 to 11635. And now I have a problem with my mini-os executing the efi/pal code (currently the getTime - function from efi). Every time the function gets called I get an trap 22 (Instruction access rights vector). The strange thing is that the trap also occurs if I don't do the mapping of the pal code. I inserted some trace messages in vcpu_itr_i() in xen to see all parameters. But it looks ok. For a test I removed the call of in ia64_itr() in efi_map_pal_code() in the linux code and nevertheless efi_gettimeofday() runs fine (linux as domU). It seems, there is another tlb entry for this page. I saw that the pal/efi stuff was reorganized in the new change-set. Can anybody give me a hint where to look in the memory handling or do some trace messages! I'm currently still not familiar enough with this stuff. Hi, After your comments I have reorganized fw memory. The PAL/SAL/EFI firmware is now between 0 and 4Kb. ACPI and system tables are between 4Kb and 12Kb. Because the size is very small there might be an entry in the TLB even without the itr. I think you should start debugging gu understand where and why the fault occurs. You may modify Xen to disp more details when a fault is reflected. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron However on ia64 this isn't sufficient. We need either for the modules to load *earlier* (such as in the initramfs) or we need to use dom0_mem=1G (for example) I have some questions, though: 1. On x86, all of the memory is assigned to dom0, then it balloons to give memory to unpriv'd domains. Why does ia64 give only 512M to dom0 instead of doing the same as x86? I don't know, but I think this is for historical reasons. Old Xen/IA64 (about 1 year ago) used only about 2GB. So I think dom0_mem was defined to 512MB. I made the patch, but the patch have a problem. I'm debug it now. 2. Juan says that he can boot x86 xen with only 128M of memory, and there's still enough physically contiguous to load blkbk and netbk when xend loads. So why does ia64 need 8x the memory to do avoid fragmentation? It seems like we must be doing something wrong for memory to fragment so quickly...! I also don't know about it. This is strange, but insmod blkbk will fail in the following case on x86. 1. chkconfig xend off 2. and do many operations after boot 3. then service xend start --- insmod blkbk fail (probably) On PAE the problem was fixed by loading blkbk/netbk in /etc/init.d/xend. This moves the module load early enough in the system boot to fix it on that arch. So the above solution is not good. If we choice the early module load solution, we should add it into rc.sysinit. 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] Memory problem with mini-os
Am Montag, 2. Oktober 2006 09:57 schrieb Tristan Gingold: Le Lundi 02 Octobre 2006 09:35, Dietmar Hahn a écrit : Hi, after my vacation I switched from xen-ia64 change-set 11039 to 11635. And now I have a problem with my mini-os executing the efi/pal code (currently the getTime - function from efi). Every time the function gets called I get an trap 22 (Instruction access rights vector). The strange thing is that the trap also occurs if I don't do the mapping of the pal code. I inserted some trace messages in vcpu_itr_i() in xen to see all parameters. But it looks ok. For a test I removed the call of in ia64_itr() in efi_map_pal_code() in the linux code and nevertheless efi_gettimeofday() runs fine (linux as domU). It seems, there is another tlb entry for this page. I saw that the pal/efi stuff was reorganized in the new change-set. Can anybody give me a hint where to look in the memory handling or do some trace messages! I'm currently still not familiar enough with this stuff. Hi, After your comments I have reorganized fw memory. To much honour ;-), The PAL/SAL/EFI firmware is now between 0 and 4Kb. ACPI and system tables are between 4Kb and 12Kb. Because the size is very small there might be an entry in the TLB even without the itr. I think you should start debugging gu understand where and why the fault occurs. You may modify Xen to disp more details when a fault is reflected. Tristan. I think I understand the problem! I use the Alternate Data TLB trap for the data translations needed for efi/pal/sal/acpi. These translations are done with access rights RW. In XEN ITC and DTC seem to be unified, so the data tlb entry is used for the translation of the efi-code. And there is no X bit set - trap 22. If I set RWX for the access rights of the data translations all runs well. The better way is a ptc.l before mapping of the pal code via a itr.i! Thanks. DIetmar. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Bind event channel of VT-i domain to vcpu 0
Hi all,
In x86 code, it was fixed about PV-on-HVM event channel in
xen-unstable.hg(cs:11698).
I fixed with same logic in IPF code.
* bind-evtchn.patch
+ bind event channels of VT-i domain to vcpu 0.
I tested that PV-on-HVM works.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 124ef96ccd1db218e798514bd306a5a727462a47
# Parent 2bfd19fc1b79c6a6712c99f875f1fbf883af3f35
Bind event channels of VT-i domain to vcpu 0
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 2bfd19fc1b79 -r 124ef96ccd1d xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Sun Oct 01 19:10:18 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_process.c Mon Oct 02 20:30:53 2006 +0900
@@ -198,7 +198,7 @@ void leave_hypervisor_tail(struct pt_reg
{
struct domain *d = current-domain;
struct vcpu *v = current;
-int callback_irq;
+
// FIXME: Will this work properly if doing an RFI???
if (!is_idle_domain(d) ) { // always comes from guest
//struct pt_regs *user_regs = vcpu_regs(current);
@@ -226,11 +226,14 @@ void leave_hypervisor_tail(struct pt_reg
// v-arch.irq_new_pending = 1;
// }
-callback_irq = d-arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ];
-if (callback_irq != 0 local_events_need_delivery()) {
-/*inject para-device call back irq*/
-v-vcpu_info-evtchn_upcall_mask = 1;
-vmx_vcpu_pend_interrupt(v, callback_irq);
+if (v-vcpu_id == 0) {
+int callback_irq =
+d-arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ];
+if (callback_irq != 0 local_events_need_delivery()) {
+/*inject para-device call back irq*/
+v-vcpu_info-evtchn_upcall_mask = 1;
+vmx_vcpu_pend_interrupt(v, callback_irq);
+}
}
if ( v-arch.irq_new_pending ) {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron I checked the fragmentation on xen/ia64 with on xen/x86. The following data is /proc/budddyinfo after starting each daemons. 1. buddyinfo of ia64 at the boottime. (dom0_mem=512MB) Mon Oct 2 20:42:24 JST 2006 --iptables--- Node 0, zone DMA 1 2 1 1 1 1 0 0 0 1 9 --iptables--- --portmap--- Node 0, zone DMA 0 1 1 1 1 0 1 0 1 0 1 --portmap--- --ssh--- Node 0, zone DMA 1 3 9 3 1 1 1 1 0 0 0 --ssh--- --sendmail--- Node 0, zone DMA 19 7 5 1 5 1 0 1 0 0 0 --sendmail--- --haldaemon--- Node 0, zone DMA 20 10 5 1 4 0 1 1 0 0 0 --haldaemon--- 2. buddyinfo of x86 at the boottime. (dom0_mem=128MB) Mon Oct 2 21:22:29 JST 2006 --iptables--- Node 0, zone DMA 47 11 4 1 0 1 8 4 1 0 11 --iptables--- --portmap--- Node 0, zone DMA 3 2 0 1 0 0 1 0 1 1 9 --portmap--- --ssh--- Node 0, zone DMA 23 3 1 1 1 1 1 3 2 0 3 --ssh--- --sendmail--- Node 0, zone DMA 26 5 4 0 0 0 4 3 3 1 1 --sendmail--- --haldaemon--- Node 0, zone DMA 44 14 23 14 2 1 1 0 1 0 0 --haldaemon--- --before stating xend--- Node 0, zone DMA 22 25 24 14 2 1 1 0 1 0 0 --before stating xend--- I think fragmentations of ia64 is a little quickly. But allocate of oder:8 is hard on also x86 at the starting of xend. My Xen/IA64 environment have 16 cpus(4 sockets, 8cores, 16threads), and Xen/x86 environment have 2core cpus(1 sockets, 2cores). The difference of the fragmentations may be caused by the number of cpus. What do you think about it? Best Regards, Akio Takebe Akio Takebe wrote: [Fri Sep 29 2006, 11:41:57AM EDT] Hmmm... But this issue was happened on x86-PAE. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 Actually with dom0_mem=512M on FC6-ia64, we can success installing blkbk on rare occasions. On PAE the problem was fixed by loading blkbk/netbk in /etc/init.d/xend. This moves the module load early enough in the system boot to fix it on that arch. However on ia64 this isn't sufficient. We need either for the modules to load *earlier* (such as in the initramfs) or we need to use dom0_mem=1G (for example) I have some questions, though: 1. On x86, all of the memory is assigned to dom0, then it balloons to give memory to unpriv'd domains. Why does ia64 give only 512M to dom0 instead of doing the same as x86? 2. Juan says that he can boot x86 xen with only 128M of memory, and there's still enough physically contiguous to load blkbk and netbk when xend loads. So why does ia64 need 8x the memory to do avoid fragmentation? It seems like we must be doing something wrong for memory to fragment so quickly...! Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: prevents itc/ptc on shared_info space
Hi,
this is a security patch: it detects itc/ptc on shared info space before the
MCA...
Tested by booting dom0+domU.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 194bb24d456da885670dfb0022f15f87c15ac0fd
# Parent 2bfd19fc1b79c6a6712c99f875f1fbf883af3f35
Prevent domains to itc/ptd in shared_info_va.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 2bfd19fc1b79 -r 194bb24d456d xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Sun Oct 01 19:10:18 2006 -0600
+++ b/xen/arch/ia64/xen/vcpu.c Mon Oct 02 13:31:13 2006 +0200
@@ -1314,12 +1314,21 @@ static inline void
static inline void
check_xen_space_overlap (const char *func, u64 base, u64 page_size)
{
+ /* Overlaps can occur only in region 7.
+ (This is an optimization to bypass all the checks). */
+ if (REGION_NUMBER (base) != 7)
+ return;
+
/* Mask LSBs of base. */
base = ~(page_size - 1);
/* FIXME: ideally an MCA should be generated... */
if (range_overlap (HYPERVISOR_VIRT_START, HYPERVISOR_VIRT_END,
- base, base + page_size))
+ base, base + page_size)
+ || range_overlap (current-domain-arch.shared_info_va,
+ current-domain-arch.shared_info_va
+ + XSI_SIZE + XMAPPEDREGS_SIZE,
+ base, base + page_size))
panic_domain (NULL, %s on Xen virtual space (%lx)\n,
func, base);
}
diff -r 2bfd19fc1b79 -r 194bb24d456d xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.h Sun Oct 01 19:10:18 2006 -0600
+++ b/xen/include/public/arch-ia64.h Mon Oct 02 13:31:13 2006 +0200
@@ -400,6 +400,7 @@ struct xen_ia64_boot_param {
#define XSI_SIZE (1 XSI_SHIFT)
/* Log size of mapped_regs area (64 KB - only 4KB is used). */
#define XMAPPEDREGS_SHIFT 12
+#define XMAPPEDREGS_SIZE (1 XMAPPEDREGS_SHIFT)
/* Offset of XASI (Xen arch shared info) wrt XSI_BASE. */
#define XMAPPEDREGS_OFS XSI_SIZE
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: PATCH: xencomm [2]
On Mon, 2006-10-02 at 10:07 +0200, Tristan Gingold wrote: I have tried to reproduce the bug but I was not able to do so. I tried to saverestore domains created with: xm create -c domU_1 memory=2400 vcpus=4 it never fails (I tried 4-5 times). According to the dump the error looks strange: dom0 tries to do an hypercall (getmemlist I suppose) into a granted page. I have slightly modified the patch to add more details in the crash printf. Could you retry with this patch ? Hi Tristan, Hmm, I'm not able to reproduce it with this patch either. Is there any functional change to this new 5a patch? I'll look back through and make sure I didn't break something merging it in last time. 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: xencomm [2]
Akio Takebe wrote: [Mon Oct 02 2006, 08:45:22AM EDT] The following data is /proc/budddyinfo after starting each daemons. 1. buddyinfo of ia64 at the boottime. (dom0_mem=512MB) Mon Oct 2 20:42:24 JST 2006 ---iptables---Node 0, zone DMA 1 2 1 1 1 1 0 0 0 1 9 ---portmap--- Node 0, zone DMA 0 1 1 1 1 0 1 0 1 0 1 ---ssh--- Node 0, zone DMA 1 3 9 3 1 1 1 1 0 0 0 ---sendmail---Node 0, zone DMA 19 7 5 1 5 1 0 1 0 0 0 ---haldaemon--- Node 0, zone DMA 20 10 5 1 4 0 1 1 0 0 0 These numbers seem considerably smaller than x86, even from the start! 2. buddyinfo of x86 at the boottime. (dom0_mem=128MB) ---iptables---Node 0, zone DMA 47 11 4 1 0 1 8 4 1 0 11 ---portmap--- Node 0, zone DMA 3 2 0 1 0 0 1 0 1 1 9 ---ssh--- Node 0, zone DMA 23 3 1 1 1 1 1 3 2 0 3 ---sendmail---Node 0, zone DMA 26 5 4 0 0 0 4 3 3 1 1 ---haldaemon--- Node 0, zone DMA 44 14 23 14 2 1 1 0 1 0 0 ---before xend--- Node 0, zone DMA 22 25 24 14 2 1 1 0 1 0 0 x86 should also have a Normal zone (i.e. non-DMA) which probably has even more available, but doesn't appear in this output. I'm guessing that the netbk and blkbk drivers aren't limited to DMA-capable pages. I think fragmentations of ia64 is a little quickly. But allocate of oder:8 is hard on also x86 at the starting of xend. My Xen/IA64 environment have 16 cpus(4 sockets, 8cores, 16threads), and Xen/x86 environment have 2core cpus(1 sockets, 2cores). The difference of the fragmentations may be caused by the number of cpus. What do you think about it? My ia64 test machine has only 2 cpus, so I don't think that's the only factor. But your data is very interesting, thanks for collecting it! Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Add missing #include xen/keyhandler.h
Keir, Please apply this to xen-3.0.3-testing and xen-unstable. It fixes a missing #include which results in an implicit declaration for initialize_keytable (introduced by my own mistake in 828c0c89d830) Thanks, Aron Signed-off-by: Aron Griffis [EMAIL PROTECTED] diff -r f426f6e646eb -r bde321653d48 xen/arch/ia64/xen/xensetup.c --- a/xen/arch/ia64/xen/xensetup.c Mon Oct 02 18:04:56 2006 +0100 +++ b/xen/arch/ia64/xen/xensetup.c Mon Oct 02 18:21:24 2006 -0400 @@ -18,6 +18,7 @@ #include xen/domain.h #include xen/serial.h #include xen/trace.h +#include xen/keyhandler.h #include asm/meminit.h #include asm/page.h #include asm/setup.h ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: PATCH: xencomm [2]
Tristan, It seems to be working pretty reliably now. I suspect my tools may have been slightly out of sync. I went ahead and applied these patches (the a version w/o the extra debug, but with the extra file headers). 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] [PATCH] avoid long interrupt mask
avoid long time interrupt masking. flush_vtlb_fro_context_switch() can be executed with interrupt enabled. -- yamahata # HG changeset patch # User [EMAIL PROTECTED] # Date 1153743925 -32400 # Node ID 1a2695d2a79a6f79826759e759a0a3d7abc13142 # Parent c3f71a4ed653b5a643abf985e05d92039b98dec7 avoid long time interrupt masking. flush_vtlb_fro_context_switch() can be executed with interrupt enabled. PATCHNAME: avoid_long_time_interrupt_masking Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r c3f71a4ed653 -r 1a2695d2a79a xen/arch/ia64/xen/domain.c --- a/xen/arch/ia64/xen/domain.cMon Oct 02 14:09:49 2006 -0600 +++ b/xen/arch/ia64/xen/domain.cMon Jul 24 21:25:25 2006 +0900 @@ -190,8 +190,8 @@ void context_switch(struct vcpu *prev, s __ia64_per_cpu_var(current_psr_ic_addr) = NULL; } } +local_irq_restore(spsr); flush_vtlb_for_context_switch(current); -local_irq_restore(spsr); context_saved(prev); } ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] add perfc counter related to vTLB flush
add perfc counter related to vTLB flush -- yamahata # HG changeset patch # User [EMAIL PROTECTED] # Date 1156405495 -32400 # Node ID 545440872f603e60a0d457ca250e3b9eceb0bf53 # Parent 1a2695d2a79a6f79826759e759a0a3d7abc13142 add perfcounter for vTLB flush. PATCHNAME: perfc_for_vtlb_flush Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r 1a2695d2a79a -r 545440872f60 xen/arch/ia64/xen/domain.c --- a/xen/arch/ia64/xen/domain.cMon Jul 24 21:25:25 2006 +0900 +++ b/xen/arch/ia64/xen/domain.cThu Aug 24 16:44:55 2006 +0900 @@ -101,6 +101,7 @@ static void flush_vtlb_for_context_switc vhpt_flush(); } local_flush_tlb_all(); + perfc_incrc(flush_vtlb_for_context_switch); } } diff -r 1a2695d2a79a -r 545440872f60 xen/arch/ia64/xen/vhpt.c --- a/xen/arch/ia64/xen/vhpt.c Mon Jul 24 21:25:25 2006 +0900 +++ b/xen/arch/ia64/xen/vhpt.c Thu Aug 24 16:44:55 2006 +0900 @@ -155,6 +155,8 @@ void vcpu_flush_vtlb_all(struct vcpu *v) /* We could clear bit in d-domain_dirty_cpumask only if domain d in not running on this processor. There is currently no easy way to check this. */ + + perfc_incrc(vcpu_flush_vtlb_all); } static void __vcpu_flush_vtlb_all(void *vcpu) @@ -178,6 +180,7 @@ void domain_flush_vtlb_all (void) __vcpu_flush_vtlb_all, v, 1, 1); } + perfc_incrc(domain_flush_vtlb_all); } static void cpu_flush_vhpt_range (int cpu, u64 vadr, u64 addr_range) @@ -200,6 +203,7 @@ void vcpu_flush_tlb_vhpt_range (u64 vadr cpu_flush_vhpt_range (current-processor, vadr, 1UL log_range); ia64_ptcl(vadr, log_range 2); ia64_srlz_i(); + perfc_incrc(vcpu_flush_tlb_vhpt_range); } void domain_flush_vtlb_range (struct domain *d, u64 vadr, u64 addr_range) @@ -236,6 +240,7 @@ void domain_flush_vtlb_range (struct dom /* ptc.ga */ ia64_global_tlb_purge(vadr,vadr+addr_range,PAGE_SHIFT); + perfc_incrc(domain_flush_vtlb_range); } static void flush_tlb_vhpt_all (struct domain *d) diff -r 1a2695d2a79a -r 545440872f60 xen/include/asm-ia64/perfc_defn.h --- a/xen/include/asm-ia64/perfc_defn.h Mon Jul 24 21:25:25 2006 +0900 +++ b/xen/include/asm-ia64/perfc_defn.h Thu Aug 24 16:44:55 2006 +0900 @@ -107,3 +107,12 @@ PERFPRIVOPADDR(get_ifa) PERFPRIVOPADDR(get_ifa) PERFPRIVOPADDR(thash) #endif + +// vhpt.c +PERFCOUNTER_CPU(vcpu_flush_vtlb_all, vcpu_flush_vtlb_all) +PERFCOUNTER_CPU(domain_flush_vtlb_all, domain_flush_vtlb_all) +PERFCOUNTER_CPU(vcpu_flush_tlb_vhpt_range, vcpu_flush_tlb_vhpt_range) +PERFCOUNTER_CPU(domain_flush_vtlb_range,domain_flush_vtlb_range) + +// domain.c +PERFCOUNTER_CPU(flush_vtlb_for_context_switch, flush_vtlb_for_context_switch) ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] add perfc counter to mm.c
add perfc counter to mm.c
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1156405572 -32400
# Node ID de4490aa054d27c50c02fdbb3b1b02c74b19e753
# Parent 545440872f603e60a0d457ca250e3b9eceb0bf53
add perfcounter to mm.c
PATCHNAME: perfc_mm_c
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 545440872f60 -r de4490aa054d xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cThu Aug 24 16:44:55 2006 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Aug 24 16:46:12 2006 +0900
@@ -1057,6 +1057,7 @@ assign_domain_page_replace(struct domain
put_page(old_page);
}
}
+perfc_incrc(assign_domain_page_replace);
}
// caller must get_page(new_page) before
@@ -1117,6 +1118,7 @@ assign_domain_page_cmpxchg_rel(struct do
domain_page_flush(d, mpaddr, old_mfn, new_mfn);
put_page(old_page);
+perfc_incrc(assign_domain_pge_cmpxchg_rel);
return 0;
}
@@ -1189,6 +1191,7 @@ zap_domain_page_one(struct domain *d, un
try_to_clear_PGC_allocate(d, page);
}
put_page(page);
+perfc_incrc(zap_dcomain_page_one);
}
unsigned long
@@ -1201,6 +1204,7 @@ dom0vp_zap_physmap(struct domain *d, uns
}
zap_domain_page_one(d, gpfn PAGE_SHIFT, INVALID_MFN);
+perfc_incrc(dom0vp_zap_physmap);
return 0;
}
@@ -1246,6 +1250,7 @@ dom0vp_add_physmap(struct domain* d, uns
get_gpfn_from_mfn(mfn) != INVALID_M2P_ENTRY);
assign_domain_page_replace(d, gpfn PAGE_SHIFT, mfn, flags);
//don't update p2m table because this page belongs to rd, not d.
+perfc_incrc(dom0vp_add_physmap);
out1:
put_domain(rd);
return error;
@@ -1277,6 +1282,7 @@ create_grant_host_mapping(unsigned long
get_gpfn_from_mfn(mfn) != INVALID_M2P_ENTRY);
assign_domain_page_replace(d, gpaddr, mfn, (flags GNTMAP_readonly)?
ASSIGN_readonly:
ASSIGN_writable);
+perfc_incrc(create_grant_host_mapping);
return GNTST_okay;
}
@@ -1336,6 +1342,7 @@ destroy_grant_host_mapping(unsigned long
BUG_ON(page_get_owner(page) == d);//try_to_clear_PGC_allocate(d, page) is
not needed.
put_page(page);
+perfc_incrc(destroy_grant_host_mapping);
return GNTST_okay;
}
@@ -1396,6 +1403,7 @@ steal_page(struct domain *d, struct page
free_domheap_page(new);
return -1;
}
+perfc_incrc(steal_page_refcount);
}
spin_lock(d-page_alloc_lock);
@@ -1465,6 +1473,7 @@ steal_page(struct domain *d, struct page
list_del(page-list);
spin_unlock(d-page_alloc_lock);
+perfc_incrc(steal_page);
return 0;
}
@@ -1482,6 +1491,8 @@ guest_physmap_add_page(struct domain *d,
assign_domain_page_replace(d, gpfn PAGE_SHIFT, mfn, ASSIGN_writable);
//BUG_ON(mfn != ((lookup_domain_mpa(d, gpfn PAGE_SHIFT) _PFN_MASK)
PAGE_SHIFT));
+
+perfc_incrc(guest_physmap_add_page);
}
void
@@ -1490,6 +1501,7 @@ guest_physmap_remove_page(struct domain
{
BUG_ON(mfn == 0);//XXX
zap_domain_page_one(d, gpfn PAGE_SHIFT, mfn);
+perfc_incrc(guest_physmap_remove_page);
}
//XXX sledgehammer.
@@ -1502,6 +1514,7 @@ domain_page_flush(struct domain* d, unsi
shadow_mark_page_dirty(d, mpaddr PAGE_SHIFT);
domain_flush_vtlb_all();
+perfc_incrc(domain_page_flush);
}
int
diff -r 545440872f60 -r de4490aa054d xen/include/asm-ia64/perfc_defn.h
--- a/xen/include/asm-ia64/perfc_defn.h Thu Aug 24 16:44:55 2006 +0900
+++ b/xen/include/asm-ia64/perfc_defn.h Thu Aug 24 16:46:12 2006 +0900
@@ -116,3 +116,17 @@ PERFCOUNTER_CPU(domain_flush_vtlb_range,
// domain.c
PERFCOUNTER_CPU(flush_vtlb_for_context_switch,
flush_vtlb_for_context_switch)
+
+// mm.c
+PERFCOUNTER_CPU(assign_domain_page_replace, assign_domain_page_replace)
+PERFCOUNTER_CPU(assign_domain_pge_cmpxchg_rel,
assign_domain_pge_cmpxchg_rel)
+PERFCOUNTER_CPU(zap_dcomain_page_one, zap_dcomain_page_one)
+PERFCOUNTER_CPU(dom0vp_zap_physmap,dom0vp_zap_physmap)
+PERFCOUNTER_CPU(dom0vp_add_physmap,dom0vp_add_physmap)
+PERFCOUNTER_CPU(create_grant_host_mapping, create_grant_host_mapping)
+PERFCOUNTER_CPU(destroy_grant_host_mapping, destroy_grant_host_mapping)
+PERFCOUNTER_CPU(steal_page_refcount, steal_page_refcount)
+PERFCOUNTER_CPU(steal_page,steal_page)
+PERFCOUNTER_CPU(guest_physmap_add_page,
guest_physmap_add_page)
+PERFCOUNTER_CPU(guest_physmap_remove_page, guest_physmap_remove_page)
+PERFCOUNTER_CPU(domain_page_flush, domain_page_flush)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] add perfc counter to p2m and m2p conversion
add perfc counter to p2m and m2p conversion
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1156405631 -32400
# Node ID dfb7cbcad569ac2028ff3fadfa6e07f84bd7e48e
# Parent de4490aa054d27c50c02fdbb3b1b02c74b19e753
add perfcounter of dom0vp_phystomach and dom0vp_machtophys
PATCHNAME: perfc_dom0vp_p2m_and_m2p
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r de4490aa054d -r dfb7cbcad569 xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c Thu Aug 24 16:46:12 2006 +0900
+++ b/xen/arch/ia64/xen/dom0_ops.c Thu Aug 24 16:47:11 2006 +0900
@@ -256,6 +256,7 @@ do_dom0vp_op(unsigned long cmd,
} else {
ret = (ret _PFN_MASK) PAGE_SHIFT;//XXX pte_pfn()
}
+perfc_incrc(dom0vp_phystomach);
break;
case IA64_DOM0VP_machtophys:
if (!mfn_valid(arg0)) {
@@ -263,6 +264,7 @@ do_dom0vp_op(unsigned long cmd,
break;
}
ret = get_gpfn_from_mfn(arg0);
+perfc_incrc(dom0vp_machtophys);
break;
case IA64_DOM0VP_zap_physmap:
ret = dom0vp_zap_physmap(d, arg0, (unsigned int)arg1);
diff -r de4490aa054d -r dfb7cbcad569 xen/include/asm-ia64/perfc_defn.h
--- a/xen/include/asm-ia64/perfc_defn.h Thu Aug 24 16:46:12 2006 +0900
+++ b/xen/include/asm-ia64/perfc_defn.h Thu Aug 24 16:47:11 2006 +0900
@@ -130,3 +130,7 @@ PERFCOUNTER_CPU(guest_physmap_add_page,
PERFCOUNTER_CPU(guest_physmap_add_page,
guest_physmap_add_page)
PERFCOUNTER_CPU(guest_physmap_remove_page, guest_physmap_remove_page)
PERFCOUNTER_CPU(domain_page_flush, domain_page_flush)
+
+// dom0vp
+PERFCOUNTER_CPU(dom0vp_phystomach, dom0vp_phystomach)
+PERFCOUNTER_CPU(dom0vp_machtophys, dom0vp_machtophys)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] don't export GPFN_ flags and shorten GPFN_INV_MASK to 1bit
don't export GPFN_xxx flags. GPFN_INV_MASK taks 4bits, but 1 bit is sufficient. I can boot domVTI with this patch. -- yamahata # HG changeset patch # User [EMAIL PROTECTED] # Date 1159844230 -32400 # Node ID b90464479100c0f240d720a517a38a4276af # Parent dfb7cbcad569ac2028ff3fadfa6e07f84bd7e48e don't export GPFN_xxx flags. GPFN_INV_MASK taks 4bits, but 1 bit is sufficient. PATCHNAME: gpfn_mask Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r dfb7cbcad569 -r b90464479555 xen/include/asm-ia64/linux-xen/asm/pgtable.h --- a/xen/include/asm-ia64/linux-xen/asm/pgtable.h Thu Aug 24 16:47:11 2006 +0900 +++ b/xen/include/asm-ia64/linux-xen/asm/pgtable.h Tue Oct 03 11:57:10 2006 +0900 @@ -68,6 +68,20 @@ #ifdef XEN #define _PAGE_VIRT_D (__IA64_UL(1) 53)/* Virtual dirty bit */ #define _PAGE_PROTNONE 0 + +/* domVTI */ +#define GPFN_MEM (0UL 60) /* Guest pfn is normal mem */ +#define GPFN_FRAME_BUFFER (1UL 60) /* VGA framebuffer */ +#define GPFN_LOW_MMIO (2UL 60) /* Low MMIO range */ +#define GPFN_PIB (3UL 60) /* PIB base */ +#define GPFN_IOSAPIC (4UL 60) /* IOSAPIC base */ +#define GPFN_LEGACY_IO (5UL 60) /* Legacy I/O base */ +#define GPFN_GFW (6UL 60) /* Guest Firmware */ +#define GPFN_HIGH_MMIO (7UL 60) /* High MMIO range */ + +#define GPFN_IO_MASK (7UL 60) /* Guest pfn is I/O type */ +#define GPFN_INV_MASK (1UL 63) /* Guest pfn is invalid */ + #else #define _PAGE_PROTNONE (__IA64_UL(1) 63) #endif diff -r dfb7cbcad569 -r b90464479555 xen/include/public/arch-ia64.h --- a/xen/include/public/arch-ia64.hThu Aug 24 16:47:11 2006 +0900 +++ b/xen/include/public/arch-ia64.hTue Oct 03 11:57:10 2006 +0900 @@ -47,18 +47,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); #ifndef __ASSEMBLY__ typedef unsigned long xen_ulong_t; - -#define GPFN_MEM (0UL 56) /* Guest pfn is normal mem */ -#define GPFN_FRAME_BUFFER (1UL 56) /* VGA framebuffer */ -#define GPFN_LOW_MMIO (2UL 56) /* Low MMIO range */ -#define GPFN_PIB (3UL 56) /* PIB base */ -#define GPFN_IOSAPIC (4UL 56) /* IOSAPIC base */ -#define GPFN_LEGACY_IO(5UL 56) /* Legacy I/O base */ -#define GPFN_GFW (6UL 56) /* Guest Firmware */ -#define GPFN_HIGH_MMIO(7UL 56) /* High MMIO range */ - -#define GPFN_IO_MASK (7UL 56) /* Guest pfn is I/O type */ -#define GPFN_INV_MASK(31UL 59) /* Guest pfn is invalid */ #define INVALID_MFN (~0UL) ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Bind event channel of VT-i domain to vcpu 0
On Mon, 2006-10-02 at 21:10 +0900, DOI Tsunehisa wrote: Hi all, In x86 code, it was fixed about PV-on-HVM event channel in xen-unstable.hg(cs:11698). I fixed with same logic in IPF code. * bind-evtchn.patch + bind event channels of VT-i domain to vcpu 0. 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
[Xen-ia64-devel] Re: PATCH: prevents itc/ptc on shared_info space
On Mon, 2006-10-02 at 15:59 +0200, Tristan Gingold wrote: Hi, this is a security patch: it detects itc/ptc on shared info space before the MCA... 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] avoid long interrupt mask
I've applied the following: 11705:1a2695d2a79a_avoid_long_time_interrupt_masking.patch 11706:545440872f60_perfc_for_vtlb_flush.patch 11707:de4490aa054d_perfc_mm_c.patch 11708:dfb7cbcad569_perfc_dom0vp_p2m_and_m2p.patch 11709:b90464479555_gpfn_mask.patch 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] [Patch][RFC] allocate all memory to dom0
Hi, all This patch change default value of dom0_mem. Current xen/ia64, default value of dom0_mem is 512MB. This patch change it from 512MB to almost total memory(like xen/x86). Signed-off-by: Akio Takebe [EMAIL PROTECTED] I test the patch. But I have a problem. I cannot boot current xen/ia64 with dom0_mem=4G. The below is boot log. \ \/ /___ _ __ |___ / / _ \_ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \|_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |(_)___/\__,_|_| |_|___/\__\__,_|_.__/|_|\___| http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0-unstable (root@) (gcc version 3.4.4 20050721 (Red Hat 3. 4.4-2)) Mon Oct 2 19:27:12 JST 2006 Latest ChangeSet: Sun Oct 01 19:10:18 2006 -0600 11701:2bfd19fc1b79 (XEN) Console output is synchronous. (XEN) Xen command line: BOOT_IMAGE=scsi0:\EFI\redhat\../xen/xen.gz- takebe dom0_mem=4G com2=115200,8n1 console=com2,vga sync_console (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) Xen patching physical address access by offset: 0x0 (XEN) find_memory: efi_memmap_walk returns max_page=bffee (XEN) Before xen_heap_start: f4129bd8 (XEN) After xen_heap_start: f4148000 (XEN) Init boot pages: 0x1d8 - 0x400. (XEN) Init boot pages: 0x800 - 0x7f708000. (XEN) Init boot pages: 0x7fe58000 - 0x7feb8000. (XEN) Init boot pages: 0x1 - 0x1c000. (XEN) Init boot pages: 0x28000 - 0x2fd99b000. (XEN) Init boot pages: 0x2fe806eb0 - 0x2fedec010. (XEN) Init boot pages: 0x2fedec070 - 0x2fedeff59. (XEN) Init boot pages: 0x2fedeffc7 - 0x2fedf3000. (XEN) Init boot pages: 0x2fef319d4 - 0x2fef4e010. (XEN) Init boot pages: 0x2fef4ea00 - 0x2ffe14000. (XEN) Init boot pages: 0x2ffe8 - 0x2fffb8000. (XEN) System RAM: 8166MB (8362688kB) (XEN) size of virtual frame_table: 20480kB (XEN) virtual machine to physical table: f3a00090 size: 4144kB (XEN) max_page: 0xbffee (XEN) Xen heap: 62MB (64224kB) (XEN) ACPI: RSDP (v002 INTEL ) @ 0x7ff0c000 (XEN) ACPI: XSDT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff0c090 (XEN) ACPI: FADT (v003 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff0c138 (XEN) ACPI: MADT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff0c230 (XEN) ACPI: DSDT (v001 Intel SR870BN4 0x INTL 0x20030918) @ 0x (XEN) SAL 3.20: Intel Corp SR870BN4 version 3.0 (XEN) SAL Platform features: BusLock (XEN) SAL: AP wakeup using external interrupt vector 0xf0 (XEN) cpu package is Multi-Core capable: number of cores=2 (XEN) cpu package is Multi-Threading capable: number of siblings=2 (XEN) avail:0x31700740, status:0x740,control: 0x3170, vm?0x100 (XEN) WARNING: no opcode provided from hardware(0)!!! (XEN) vm buffer size: 1048576, order: 6 (XEN) cpu_init: current=f40d8000 (XEN) vm_buffer: 0xf7e0 (XEN) vhpt_init: vhpt paddr=0x1fffe, end=0x1fffe (XEN) iosapic_system_init: Disabling PC-AT compatible 8259 interrupts (XEN) ACPI: Local APIC address e800fee0 (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0xc4] lsapic_eid[0x18] enabled) (XEN) CPU 0 (0xc418) enabled (BSP) (XEN) ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0xc6] lsapic_eid[0x18] enabled) (XEN) CPU 1 (0xc618) enabled (XEN) ACPI: LSAPIC (acpi_id[0x02] lsapic_id[0xc1] lsapic_eid[0x18] enabled) (XEN) CPU 2 (0xc118) enabled (XEN) ACPI: LSAPIC (acpi_id[0x03] lsapic_id[0xc3] lsapic_eid[0x18] enabled) (XEN) CPU 3 (0xc318) enabled (XEN) ACPI: LSAPIC (acpi_id[0x04] lsapic_id[0xc5] lsapic_eid[0x18] enabled) (XEN) CPU 4 (0xc518) enabled (XEN) ACPI: LSAPIC (acpi_id[0x05] lsapic_id[0xc7] lsapic_eid[0x18] enabled) (XEN) CPU 5 (0xc718) enabled (XEN) ACPI: LSAPIC (acpi_id[0x06] lsapic_id[0xc0] lsapic_eid[0x98] enabled) (XEN) CPU 6 (0xc098) enabled (XEN) ACPI: LSAPIC (acpi_id[0x07] lsapic_id[0xc2] lsapic_eid[0x98] enabled) (XEN) CPU 7 (0xc298) enabled (XEN) ACPI: LSAPIC (acpi_id[0x08] lsapic_id[0xc4] lsapic_eid[0x98] enabled) (XEN) CPU 8 (0xc498) enabled (XEN) ACPI: LSAPIC (acpi_id[0x09] lsapic_id[0xc6] lsapic_eid[0x98] enabled) (XEN) CPU 9 (0xc698) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0a] lsapic_id[0xc1] lsapic_eid[0x98] enabled) (XEN) CPU 10 (0xc198) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0b] lsapic_id[0xc3] lsapic_eid[0x98] enabled) (XEN) CPU 11 (0xc398) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0c] lsapic_id[0xc5] lsapic_eid[0x98] enabled) (XEN) CPU 12 (0xc598) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0d] lsapic_id[0xc7] lsapic_eid[0x98] enabled) (XEN) CPU 13 (0xc798) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0e] lsapic_id[0xc0] lsapic_eid[0x18] enabled) (XEN) CPU 14 (0xc018) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0f]
[Xen-ia64-devel] [PATCH] make MAX_SKBUFF_ORDER page size independent
make MAX_SKBUFF_ORDER page size independent.
Presumably the original value 4 comes from 64KB = (4KB 4) which is
ip packet maximum size.
However page size is not always 4KB. e.g. IA64 default page size is 16KB.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1159851774 -32400
# Node ID 93590d295f381e50cd95a161379da3ec9129fdfe
# Parent 121ea4bab59bed2bbcb6fee321d49d138954fcfd
make MAX_SKBUFF_ORDER page size independent.
Presumably the original value 4 comes from 64KB = (4KB 4) which is
ip packet maximum size.
However page size is not always 4KB. e.g. IA64 default page size is 16KB.
PATCHNAME: max_skbuff_order
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 121ea4bab59b -r 93590d295f38
linux-2.6-xen-sparse/drivers/xen/core/skbuff.c
--- a/linux-2.6-xen-sparse/drivers/xen/core/skbuff.cTue Oct 03 13:46:08
2006 +0900
+++ b/linux-2.6-xen-sparse/drivers/xen/core/skbuff.cTue Oct 03 14:02:54
2006 +0900
@@ -18,7 +18,7 @@
/*static*/ kmem_cache_t *skbuff_cachep;
EXPORT_SYMBOL(skbuff_cachep);
-#define MAX_SKBUFF_ORDER 4
+#define MAX_SKBUFF_ORDER (16 - PAGE_SHIFT)
static kmem_cache_t *skbuff_order_cachep[MAX_SKBUFF_ORDER + 1];
static struct {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
