RE: [Xen-ia64-devel] VT-i: general exception
From: Tristan Gingold
Sent: 2006?4?11? 16:47
Le Mardi 11 Avril 2006 03:17, Xu, Anthony a écrit :
From: Tristan Gingold
Sent: 2006?4?11? 0:03
To: xen-ia64-devel@lists.xensource.com
Subject: [Xen-ia64-devel] VT-i: general exception
Hi,
inside vmx_ivt.S:
// 0x5400 Entry 24 (size 16 bundles) General Exception (5,32,34,36,38,39)
ENTRY(vmx_general_exception)
VMX_DBG_FAULT(24)
VMX_FAULT(24)
//VMX_REFLECT(24)
END(vmx_general_exception)
IIRC, VMX_FAULT is an infinite loop. Therefore, in case of general
exception raised at the hots IVT, xen locks.
Is it a bug or something not finished ?
It's not a bug, normally general exception will not happen in guest,
If it does happen, that means something wrong, it was used for
debugging.
???
Try this program:
int main(void)
{
int a = *(volatile int *)0xf000;
}
This locks up Xen!
Ideally gp fault should be injected into guest.
Again, this was only used for debugging tricky issue
happening inside VMM.
Thanks,
Anthony
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] VT-i: general exception
Le Mardi 11 Avril 2006 10:49, Xu, Anthony a écrit :
From: Tristan Gingold
Sent: 2006?4?11? 16:47
Le Mardi 11 Avril 2006 03:17, Xu, Anthony a écrit :
From: Tristan Gingold
Sent: 2006?4?11? 0:03
To: xen-ia64-devel@lists.xensource.com
Subject: [Xen-ia64-devel] VT-i: general exception
Hi,
inside vmx_ivt.S:
// 0x5400 Entry 24 (size 16 bundles) General Exception
(5,32,34,36,38,39) ENTRY(vmx_general_exception)
VMX_DBG_FAULT(24)
VMX_FAULT(24)
//VMX_REFLECT(24)
END(vmx_general_exception)
IIRC, VMX_FAULT is an infinite loop. Therefore, in case of general
exception raised at the hots IVT, xen locks.
Is it a bug or something not finished ?
It's not a bug, normally general exception will not happen in guest,
If it does happen, that means something wrong, it was used for
debugging.
???
Try this program:
int main(void)
{
int a = *(volatile int *)0xf000;
}
This locks up Xen!
Ideally gp fault should be injected into guest.
No. Xen-Vti set 'opcode' virtual env parameter to 1.
Therefore according to 5.2.2, some GF are raised at the *host* IVT.
Again, this was only used for debugging tricky issue
happening inside VMM.
This is wrong. This simple program locks Xen-Vti, but it shouldn't.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] VT-i: general exception
Ok I'll modify this. Thanks, Anthony Ideally gp fault should be injected into guest. No. Xen-Vti set 'opcode' virtual env parameter to 1. Therefore according to 5.2.2, some GF are raised at the *host* IVT. Again, this was only used for debugging tricky issue happening inside VMM. This is wrong. This simple program locks Xen-Vti, but it shouldn't. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
On Tue, Apr 11, 2006 at 09:29:18AM +0100, Tristan Gingold wrote:
Le Mardi 11 Avril 2006 03:52, Isaku Yamahata a écrit :
Thank you for testing.
On Mon, Apr 10, 2006 at 03:52:52PM +0100, Tristan Gingold wrote:
Le Vendredi 07 Avril 2006 06:16, Isaku Yamahata a écrit :
Hello.
I attached the P2M/VP model patches take 4 for the change set
9492:2133fb78dba3cf6b6b88d1566fc5cc9de3039f43.
Please comments/request/review.
I am testing this on my FAME-C.
Currently it doesn't work: this is an infinite loop in an mpt driver.
I will check how it does handle DMA.
It seems wrong dma address is used.
My test environment is Tiger-2. Mpt driver is used.
I encountered similar case before, but I don't remember clearly.
In fact I think it is due to the bug below.
It seems that the IOSAPIC area is not mapped to dom0.
Does the following patch make difference?
Could you send the all log?
diff -r e2003842daeb xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cMon Apr 10 15:08:03 2006 +0900
+++ b/xen/arch/ia64/xen/domain.cTue Apr 11 18:21:34 2006 +0900
@@ -752,6 +752,7 @@ assign_domain_mmio_page(struct domain *d
if (size == 0) {
printk(%s: domain %p mpaddr 0x%lx size = 0x%lx\n,
__func__, d, mpaddr, size);
+size = PAGE_SIZE;
}
assign_domain_same_page(d, mpaddr, size);
return mpaddr;
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
Le Mardi 11 Avril 2006 11:23, Isaku Yamahata a écrit : On Tue, Apr 11, 2006 at 09:29:18AM +0100, Tristan Gingold wrote: Le Mardi 11 Avril 2006 03:52, Isaku Yamahata a écrit : Thank you for testing. On Mon, Apr 10, 2006 at 03:52:52PM +0100, Tristan Gingold wrote: Le Vendredi 07 Avril 2006 06:16, Isaku Yamahata a écrit : Hello. I attached the P2M/VP model patches take 4 for the change set 9492:2133fb78dba3cf6b6b88d1566fc5cc9de3039f43. Please comments/request/review. I am testing this on my FAME-C. Currently it doesn't work: this is an infinite loop in an mpt driver. I will check how it does handle DMA. It seems wrong dma address is used. My test environment is Tiger-2. Mpt driver is used. I encountered similar case before, but I don't remember clearly. In fact I think it is due to the bug below. It seems that the IOSAPIC area is not mapped to dom0. After more reading, there is an inconsistency between memmap and MADT on our system! Thanks, Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] VTi: break handling
Hi, in vmx_ivt.S: // 0x2c00 Entry 11 (size 64 bundles) Break instruction (33) ENTRY(vmx_break_fault) VMX_DBG_FAULT(11) mov r31=pr mov r19=11 mov r30=cr.iim movl r29=0x1100 ;; cmp.eq p6,p7=r30,r0 (p6) br.sptk vmx_fault_11 ;; cmp.eq p6,p7=r29,r30 (p6) br.dptk.few vmx_hypercall_dispatch (p7) br.sptk.many vmx_dispatch_break_fault ;; VMX_FAULT(11); END(vmx_break_fault) Is the '' section debug code ? I fear a bug here. Thank you for comments, Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Cleanup to irq.c
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月11日 19:33 Le Mardi 11 Avril 2006 13:15, Tian, Kevin a écrit : This patch is a big cleanup to irq.c, with only real necessary interfaces kept now. The irq subsystem of xen is very simple since most external devices are controlled by dom0. Also especially there's no need to keep CONFIG_XEN everywhere, since this file is already out of sync of linux version for a long time. Actually xen defines irq related structures differently and it's worthy of creating a xen specific version here. Good cleanup. Maybe we could also merge irq.c and xenirq.c ? Here it comes. Alex, please apply this one on top of previous clean_irq.patch. Remove xenirq.c. Signed-off-by Kevin Tian [EMAIL PROTECTED] Thanks, Kevin remove_xenirq.patch Description: remove_xenirq.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] VTi: break handling
Le Mardi 11 Avril 2006 13:41, Xu, Anthony a écrit : From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tristan Gingold Sent: 2006?4?11? 19:04 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] VTi: break handling Hi, in vmx_ivt.S: // 0x2c00 Entry 11 (size 64 bundles) Break instruction (33) ENTRY(vmx_break_fault) VMX_DBG_FAULT(11) mov r31=pr mov r19=11 mov r30=cr.iim movl r29=0x1100 ;; cmp.eq p6,p7=r30,r0 (p6) br.sptk vmx_fault_11 ;; cmp.eq p6,p7=r29,r30 (p6) br.dptk.few vmx_hypercall_dispatch (p7) br.sptk.many vmx_dispatch_break_fault ;; VMX_FAULT(11); END(vmx_break_fault) Is the '' section debug code ? I fear a bug here. It was used for debug. Break 0, its opcode is 0, Usually break 0 is not used by linux kernel and application. When break 0 is executed, it usually means some thing wrong. Sure, but if an application does break 0, it locks up Xen! Maybe we should add a check. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
On Tue, 2006-04-11 at 21:59 +0800, Tian, Kevin wrote: From: Tristan Gingold [mailto:[EMAIL PROTECTED] * Performances ? There should be no obvious difference. The importance here is that this patch is only an intermediate step toward final solution. It makes more sense to measure performance at the last step when all pirq/virq/ipi are bound to this path. Finally it should be better. Also please note this is necessary feature requirement to reuse common architecture and thus support more advanced features easily just like Isaku's p2m effort. The performance can be always tuned on top of this path gradually. Kevin, It might be a good idea to try this with Isaku's current set of patches. I saw ~10x performance decrease in network performance from domU with this patch applied (10MB/s+ to 1MB/s). Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
I was also able to get networking working with Isaku's patches
and Alex's. Hooray! For the last eight months, I have gulped
as I told people that Xen/ia64 doesn't support networking.
No longer!
Domo arigato, Yamahata-san! Free beer (or sake) for you at
the next summit!
Dan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Williamson, Alex (Linux Kernel Dev)
Sent: Monday, April 10, 2006 2:08 PM
To: Isaku Yamahata
Cc: xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
On Mon, 2006-04-10 at 10:51 -0600, Alex Williamson wrote:
On Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata wrote:
9512:f5d0a531cb58_dom0_vp_model_xen_part.patch
I'm having trouble with the legacy VGA memory descriptor
section of
this patch.
I managed to get my system booting with the patch below
(2-way, w/
1GB RAM). Networking works, yeah! The main changes here are that I
removed the fabricated MDT entries describing the legacy VGA space,
added EFI_ACPI_RECLAIM_MEMORY to the memory types mapped, and
sorted the
resulting memory descriptor table. I also included the hack to avoid
calling assign_domain_mmio_page() for large MMIO ranges. Minor nit,
we're still subtracting IA64_GRANULE_SIZE from the MDT entry for
conventional memory, but we're not adding in the granule at the end of
memory like we used to.
I also had to make a change to the -xen kernel which is not shown
here. The sal_cache_flush_check() appears to be causing us
some trouble
again with the P2M/VP patches (MCA'd on my system), so I commented out
the call to in in arich/ia64/kernel/sal.c:ia64_sal_init(). Thanks,
Alex
--
Alex Williamson HP Linux Open Source Lab
--- xen/xen/arch/ia64/xen/dom_fw.c2006-04-10
13:17:31.0 -0600
+++ xen/xen/arch/ia64/xen/dom_fw.c2006-04-10
13:15:21.0 -0600
@@ -10,6 +10,7 @@
#include asm/pgalloc.h
#include linux/efi.h
+#include linux/sort.h
#include asm/io.h
#include asm/pal.h
#include asm/sal.h
@@ -600,9 +601,14 @@
u64 end = start + (md-num_pages EFI_PAGE_SHIFT);
if (md-type == EFI_MEMORY_MAPPED_IO ||
-md-type == EFI_MEMORY_MAPPED_IO_PORT_SPACE)
+md-type == EFI_MEMORY_MAPPED_IO_PORT_SPACE) {
+
+if (md-type == EFI_MEMORY_MAPPED_IO
+((md-num_pages EFI_PAGE_SHIFT) 0x1UL))
+return 0;
+
paddr = assign_domain_mmio_page(d, start, end - start);
-else
+} else
paddr = assign_domain_mach_page(d, start, end - start);
#else
paddr = md-phys_addr;
@@ -610,6 +616,7 @@
BUG_ON(md-type != EFI_RUNTIME_SERVICES_CODE
md-type != EFI_RUNTIME_SERVICES_DATA
+ md-type != EFI_ACPI_RECLAIM_MEMORY
md-type != EFI_MEMORY_MAPPED_IO
md-type != EFI_MEMORY_MAPPED_IO_PORT_SPACE);
@@ -626,6 +633,18 @@
return 0;
}
+static int
+efi_mdt_cmp(const void *a, const void *b)
+{
+ const efi_memory_desc_t *x = a, *y = b;
+
+ if (x-phys_addr y-phys_addr)
+ return 1;
+ if (x-phys_addr y-phys_addr)
+ return -1;
+ return 0;
+}
+
static struct ia64_boot_param *
dom_fw_init (struct domain *d, const char *args, int arglen,
char *fw_mem, int fw_mem_size)
{
@@ -834,6 +853,7 @@
/* simulate 1MB free memory at physical address zero */
MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 0);//XXX
#else
+#if 0
//XXX dom0 should use VGA?
#define VGA_RAM_START 0xb8000
#define VGA_RAM_END 0xc
@@ -852,6 +872,7 @@
pcolour_map_end = pcolour_map + VGA_CMAPSZ * 8;
MAKE_MD(EFI_LOADER_DATA, EFI_MEMORY_WB, 0 * MB,
pvga_start, 1);
MAKE_MD(EFI_LOADER_DATA, EFI_MEMORY_WB,
pcolour_map_end, 1 * MB, 1);
+#endif /* 0 */
#endif
/* hypercall patches live here, masquerade as
reserved PAL memory */
MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB,HYPERCALL_START,HYPERCALL_END, 0);
@@ -890,6 +911,8 @@
// for ACPI table.
efi_memmap_walk_type(EFI_RUNTIME_SERVICES_DATA,
dom_fw_dom0_passthrough, arg);
+efi_memmap_walk_type(EFI_ACPI_RECLAIM_MEMORY,
+ dom_fw_dom0_passthrough, arg);
efi_memmap_walk_type(EFI_MEMORY_MAPPED_IO,
dom_fw_dom0_passthrough, arg);
efi_memmap_walk_type(EFI_MEMORY_MAPPED_IO_PORT_SPACE,
@@ -902,8 +925,10 @@
#ifndef CONFIG_XEN_IA64_DOM0_VP
MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 1);
#else
+#if 0
MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB, 0 * MB,
VGA_RAM_START, 1);
MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,
VGA_COLOURMAP_END, 1*MB, 1);
+#endif /* 0 */
#endif
RE: [Xen-ia64-devel] [PATCH] Cleanup to irq.c
BTW, one confusing point here is serial_input_init() which hard coded a vector (0x30), which happens to conflict with eth0 vector on my tiger box. What's the purpose of this registration? Actually the registration here is bogus which never severs the purpose. Before my patch, previous logic simply injects that vector (0x30) into guest since it's not timer/ipi. Even xen wants to handle this vector, the hw_interrupt_type assocated with this vector is no_irq_type which is also bogus. Since it doesn't work as the code wants, I simply disabled the serial_input_init to avoid unnecessary warnings like Unexpected irq vector 0x30 on cpu 0. Never understood its purpose! Tristan. Hardcoding 0x30 for keyboard input is very old code that goes back to vBlades. It's possible that it is necessary for running Xen on ski... I'm not sure. Dan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 2:56 On Tue, 2006-04-11 at 21:59 +0800, Tian, Kevin wrote: From: Tristan Gingold [mailto:[EMAIL PROTECTED] * Performances ? There should be no obvious difference. The importance here is that this patch is only an intermediate step toward final solution. It makes more sense to measure performance at the last step when all pirq/virq/ipi are bound to this path. Finally it should be better. Also please note this is necessary feature requirement to reuse common architecture and thus support more advanced features easily just like Isaku's p2m effort. The performance can be always tuned on top of this path gradually. Kevin, It might be a good idea to try this with Isaku's current set of patches. I saw ~10x performance decrease in network performance from domU with this patch applied (10MB/s+ to 1MB/s). Thanks, Alex Hi, Alex, Could you provide something about your test environment, and then I can try identical steps as yours to see what's the bottleneck? For example: - dom0 memory size - domU memory size - How do you measure the network throughput? BTW, Isaku's patch is upon Rev 9492, and then I'll also measure upon that version. Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
On Wed, 2006-04-12 at 10:18 +0800, Tian, Kevin wrote: Hi, Alex, Could you provide something about your test environment, and then I can try identical steps as yours to see what's the bottleneck? For example: - dom0 memory size - domU memory size - How do you measure the network throughput? BTW, Isaku's patch is upon Rev 9492, and then I'll also measure upon that version. Hi Kevin, My dom0 memory is the default 512MB, domU is 1GB (7GB in the system, 2-way w/ default vcpu to phys cpu mappings). My throughput test is simply pulling a ~300MB file from a local server using wget. Something like: wget -O /dev/null http://local.server/big_file Wget provides a progress report and average throughput at the end of the transfer. Let me know if you get different results, I tried several times and seemed to get consistently degraded performance with the event callback patch. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 10:40 On Wed, 2006-04-12 at 10:18 +0800, Tian, Kevin wrote: Hi, Alex, Could you provide something about your test environment, and then I can try identical steps as yours to see what's the bottleneck? For example: - dom0 memory size - domU memory size - How do you measure the network throughput? BTW, Isaku's patch is upon Rev 9492, and then I'll also measure upon that version. Hi Kevin, My dom0 memory is the default 512MB, domU is 1GB (7GB in the system, 2-way w/ default vcpu to phys cpu mappings). My throughput test is simply pulling a ~300MB file from a local server using wget. Something like: wget -O /dev/null http://local.server/big_file Wget provides a progress report and average throughput at the end of the transfer. Let me know if you get different results, I tried several times and seemed to get consistently degraded performance with the event callback patch. Thanks, OK, thanks for info. I'm currently building the tree and will test soon. BTW, do you have any extra steps beside normal flow to setup the network for domU? Another side question I'm curious is, how about the bandwidth of your physical NIC? Is 10M an acceptable data to you regarding Isaku's p2m patch, which may reveal us the space for improvement later? :-) Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
On Wed, 2006-04-12 at 10:49 +0800, Tian, Kevin wrote: OK, thanks for info. I'm currently building the tree and will test soon. BTW, do you have any extra steps beside normal flow to setup the network for domU? For me it was simply commenting out the vif = [ '' ] line in my config file. Then when I run xend start (it takes longer) and sets up a bridge and a few other network device. domU boots up, sees an eth0 device and it's configurable via dhcp. Another side question I'm curious is, how about the bandwidth of your physical NIC? Is 10M an acceptable data to you regarding Isaku's p2m patch, which may reveal us the space for improvement later? :-) The testing I've done has not been 100% scientific. I'm not on an isolated network and the server I'm pulling from is not dedicated for this testing. I'm currently seeing ~95MB/s for the same test from dom0 while domU is still getting ~10MB/s. The bridge driver in dom0 is taking a some unaligned accesses, which may or may not be a significant factor for throughput. It's possible I'm only seeing a few of them because of the printk rate limited in the unaligned code. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
Bad news is that p2m patch doesn't work for me yet. Dom0: keyboard doesn't work with INIT: Id S1 respawning too fast: disabled for 5 minute shown there. But network can work DomU: After xend start and xm create, domU hangs at similar place reported by Tristan. Seems mmio is not mapped correctly in p2m table... Did I miss anything else aside from the patch sets by Isaku? Thanks, Kevin (XEN) xen-event-channel using irq 233 (XEN) lookup_domain_mpa: bad mpa 0xfee0 ( 0x2000) (XEN) lookup_domain_mpa: d 0xf410e1b8 id 1 current 0xf42f8000 id 0 (XEN) (XEN) Call Trace: (XEN) [f40818d0] show_stack+0x80/0x90 (XEN) sp=f42ffc00 bsp=f42f8dc8 (XEN) [f40487a0] lookup_domain_mpa+0x180/0x200 (XEN) sp=f42ffdd0 bsp=f42f8da0 (XEN) [f405a060] translate_domain_pte+0xe0/0x170 (XEN) sp=f42ffdd0 bsp=f42f8d68 (XEN) [f40624c0] vcpu_itc_d+0xb0/0x1b0 (XEN) sp=f42ffdd0 bsp=f42f8d28 (XEN) [f4057f80] ia64_hyperprivop+0x190/0x600 (XEN) sp=f42ffde0 bsp=f42f8cf8 (XEN) [f405bbc0] ia64_handle_break+0x150/0x280 (XEN) sp=f42ffe00 bsp=f42f8cb8 (XEN) [f4080500] ia64_leave_kernel+0x0/0x310 (XEN) sp=f42ffe00 bsp=f42f8cb8 (XEN) [a0019090] ??? (XEN) sp=f430 bsp=f42f8c98 (XEN) [a00100053b40] ??? (XEN) sp=f43 From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 11:15 On Wed, 2006-04-12 at 10:49 +0800, Tian, Kevin wrote: OK, thanks for info. I'm currently building the tree and will test soon. BTW, do you have any extra steps beside normal flow to setup the network for domU? For me it was simply commenting out the vif = [ '' ] line in my config file. Then when I run xend start (it takes longer) and sets up a bridge and a few other network device. domU boots up, sees an eth0 device and it's configurable via dhcp. Another side question I'm curious is, how about the bandwidth of your physical NIC? Is 10M an acceptable data to you regarding Isaku's p2m patch, which may reveal us the space for improvement later? :-) The testing I've done has not been 100% scientific. I'm not on an isolated network and the server I'm pulling from is not dedicated for this testing. I'm currently seeing ~95MB/s for the same test from dom0 while domU is still getting ~10MB/s. The bridge driver in dom0 is taking a some unaligned accesses, which may or may not be a significant factor for throughput. It's possible I'm only seeing a few of them because of the printk rate limited in the unaligned code. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
On Wed, 2006-04-12 at 11:22 +0800, Tian, Kevin wrote: Bad news is that p2m patch doesn't work for me yet. Dom0: keyboard doesn't work with INIT: Id S1 respawning too fast: disabled for 5 minute shown there. But network can work DomU: After xend start and xm create, domU hangs at similar place reported by Tristan. Seems mmio is not mapped correctly in p2m table... Did I miss anything else aside from the patch sets by Isaku? I'm using Isaku's patch set plus the patch I sent in the same thread that makes it work on zx1 systems. That patch may or may not help you. One important thing that I think it does is sort the MDT created for dom0. I also had to add EFI_ACPI_RECLAIM_MEMORY to the MDT entry types that get added for dom0. For me this included the area where the ACPI tables live. You may want to look at your MDT and see if there's another type you can add that will cover 0xfee0. BTW, the 8250 serial driver is disabled with the config files provided in Isaku's patches, so the serial console is only good for output with them. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 11:30 On Wed, 2006-04-12 at 11:22 +0800, Tian, Kevin wrote: Bad news is that p2m patch doesn't work for me yet. Dom0: keyboard doesn't work with INIT: Id S1 respawning too fast: disabled for 5 minute shown there. But network can work DomU: After xend start and xm create, domU hangs at similar place reported by Tristan. Seems mmio is not mapped correctly in p2m table... Did I miss anything else aside from the patch sets by Isaku? I'm using Isaku's patch set plus the patch I sent in the same thread that makes it work on zx1 systems. That patch may or may not help you. I'll give it a try. One important thing that I think it does is sort the MDT created for dom0. I also had to add EFI_ACPI_RECLAIM_MEMORY to the MDT entry types that get added for dom0. For me this included the area where the ACPI tables live. You may want to look at your MDT and see if there's another type you can add that will cover 0xfee0. BTW, the 8250 OK serial driver is disabled with the config files provided in Isaku's patches, so the serial console is only good for output with them. Thanks, See it now. So that's not issue. BTW, when you observed domU network degradation, how about the network of dom0? If dom0 is not affected, it's obvious that the whole event path is placed lower priority than whole interrupt path, and thus affects virtual drivers. If that's the case, I'll check whether some logic can be added to match original flow. Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Add event callback for xen/ia64
On Wed, 2006-04-12 at 12:00 +0800, Tian, Kevin wrote: BTW, when you observed domU network degradation, how about the network of dom0? If dom0 is not affected, it's obvious that the whole event path is placed lower priority than whole interrupt path, and thus affects virtual drivers. If that's the case, I'll check whether some logic can be added to match original flow. It appears dom0 is not affected and has good throughput. Here's an interesting observation though; if I wget from dom0 and domU at the same time, dom0 is a little slower (~82MB/s), but the domU throughput actually increases while the wget in dom0 is running. According to nload, domU's throughput nearly doubles for the brief time dom0's wget is running. Even wget'ing a different file off the server with dom0 causes domUs wget to speed up. Perhaps an indication that your priority hunch is correct? Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
From: Isaku Yamahata
Sent: 2006年4月11日 17:23
It seems that the IOSAPIC area is not mapped to dom0.
Does the following patch make difference?
Could you send the all log?
Hi, Isaku,
If the 0xfae is the address of one IOSAPIC area, why
doesn't it get mapped at dom_fw_init? From your patch, dom_fw_dom0_passthrough
should already construct mapping
for entries exported to dom0. So instead the problematic point
may be like Alex's case, where the type of 0xfae area is a
new one out of the comparison in current code. Maybe Tristan
can confirm this point.
In my test, domU can boot however with two stack dumps.
One for 0xfee, and another for 0xc019064 (0x60). Previous
one is related to IPI which will disappear when guest SMP is ready.
The later one shouldn't be there since domU shouldn't have access
to legacy I/O in current model (Later may change for driver domain). That's an
access to keyboard port possibly because now xen0/xenU
is compiled as one image with more drivers added. Maybe it's better
for us to map all 64M mmio area of domU to a dummy page at current
stage, to remove warnings and walk around some native drivers
within domU. Later when driver domain is added, we can map specific
mmio page to machine mmio range per configuration.
Thanks,
Kevin
diff -r e2003842daeb xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cMon Apr 10 15:08:03 2006
+0900
+++ b/xen/arch/ia64/xen/domain.cTue Apr 11 18:21:34 2006
+0900
@@ -752,6 +752,7 @@ assign_domain_mmio_page(struct domain *d
if (size == 0) {
printk(%s: domain %p mpaddr 0x%lx size = 0x%lx\n,
__func__, d, mpaddr, size);
+size = PAGE_SIZE;
}
assign_domain_same_page(d, mpaddr, size);
return mpaddr;
--
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] Add event callback for xen/ia64
From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 13:24 It appears dom0 is not affected and has good throughput. Here's an interesting observation though; if I wget from dom0 and domU at the same time, dom0 is a little slower (~82MB/s), but the domU throughput actually increases while the wget in dom0 is running. According to nload, domU's throughput nearly doubles for the brief time dom0's wget is running. Even wget'ing a different file off the server with dom0 causes domUs wget to speed up. Perhaps an indication that your priority hunch is correct? Thanks, In contrast, w/o the event channel patch, domU is unaffected by a concurrent wget in dom0 (fairly constant ~10.5MB/s). However, dom0 only runs at around 9MB/s while domU's transfer is running. Alex This may be explained as following: Before apply my patch, all the inter-domain events are bound a vector 233 which is higher than any external device interrupts. In this case, vnif request is always handled immediately without delay however real nic interrupt is responded with lower priority. By this way, the vnif path is high satisfied, however the normal eth0 driver of dom0 is affected a lot by virtual driver(vbd/vnif). Thus dom0's network output is decreased in this way After applying my patch, all the inter-domain events are placed lower than all interrupt vectors. So in contrast, the real nic traffic can be handled immediately while requests from virtual drivers are delayed/pended a lot by any interrtups. So domU network output decreased. Actually this is why event channel mechanism is proposed by xen/x86 and we're now approaching ia64 to this direction too. Current patch I sent out is only an intermediate step which have two separate paths for events and interrupts. Finally there'll be only one event path and at that time we can do more fine-grained control to the priority per event. So do you think whether this patch is available for check-in now? We can do more accurate tuning after the whole model is ready and p2m patch is merged in. Anyway, I'm still making some measurement now. I may provide a version matching current behavior if you like, for example increasing event path priority, which however may not worth doing since it's only temporary solution. :-) Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
