Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
On Mon, Apr 10, 2006 at 02:08:18PM -0600, Alex Williamson wrote:
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.
Hi Alex.
What was the problem with the legacy VGA space?
In case !CONFIG_XEN_IA64_DOM0_VP, the MDT which xen arranges says
to Linux that [0*MB, 1*MB] is usable.
So Linux uses the area, however Linux VGA driver writes its space
without any checks to check vga existance.
It results in data corruption. (the check is done at very early stage
of booting so that such corruption might not be a issue.)
I'm guessing that the following line should be fixed.
The legacy vga area should be used by Linux at least.
MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 1);
On the other hand in case CONFIG_XEN_IA64_DOM0_VP,
you just commented out the following two lines.
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);
Does it mean that the simulation of 1MB free memory at physical
address zero is unnecessary?
I.e Should the following patch applied?
--- dom_fw.c2006-04-15 03:15:53.0 +0900
+++ dom_fw.c_vga.c 2006-04-21 15:02:28.0 +0900
@@ -811,8 +811,6 @@ dom_fw_init (struct domain *d, const cha
unsigned long last_start = max_page PAGE_SHIFT;
unsigned long last_end = last_start + IA64_GRANULE_SIZE;
- /* simulate 1MB free memory at physical address zero */
- MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 0);
/* hypercall patches live here, masquerade as reserved PAL
memory */
MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB,HYPERCALL_START,HYPERCALL_END, 0);
MAKE_MD(EFI_CONVENTIONAL_MEMORY,EFI_MEMORY_WB,HYPERCALL_END,maxmem-IA64_GRANULE_SIZE,
0);
@@ -836,7 +834,6 @@ dom_fw_init (struct domain *d, const cha
else MAKE_MD(EFI_RESERVED_TYPE,0,0,0,0);
}
else {
- MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 1);
/* hypercall patches live here, masquerade as reserved PAL
memory */
MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB,HYPERCALL_START,HYPERCALL_END, 1);
MAKE_MD(EFI_CONVENTIONAL_MEMORY,EFI_MEMORY_WB,HYPERCALL_END,maxmem, 1);
--
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
On Fri, 2006-04-21 at 15:04 +0900, Isaku Yamahata wrote: Hi Alex. What was the problem with the legacy VGA space? Hi Isaku, There are several problem as far as I can tell. First, what if the system doesn't have legacy VGA? HP has several systems that might fall into this category. We're assuming something is there that may not exist, and we're also perhaps assuming a more complete legacy address space than may exist. The next problem is that the MDT provided by the platform should contain entries for the VGA space. If it does, then the real and fabricate VGA ranges overlap in the MDT provided to dom0. I believe HP zx1 systems report the 0xA range as an MMIO range when VGA is present. The Linux kernel does check the type of memory when deciding whether to initialize VGA. If the 0xA range is anything other than conventional memory, we'll probe for VGA. In case !CONFIG_XEN_IA64_DOM0_VP, the MDT which xen arranges says to Linux that [0*MB, 1*MB] is usable. So Linux uses the area, however Linux VGA driver writes its space without any checks to check vga existance. It results in data corruption. (the check is done at very early stage of booting so that such corruption might not be a issue.) Perhaps we simply need to replicate the platform MDT entries for anything below 1MB and set these up for identity mapping. If the platform doesn't report anything there, it will only be a 1MB hole in the address space. I'm guessing that the following line should be fixed. The legacy vga area should be used by Linux at least. MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 1); On the other hand in case CONFIG_XEN_IA64_DOM0_VP, you just commented out the following two lines. 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); Does it mean that the simulation of 1MB free memory at physical address zero is unnecessary? I would say yes. I think we should copy the platform MDT entries for anything below 1MB. I'm afraid that some platforms may not have MDT entries describing legacy spaces, or else I would suggest a smarter approach to reclaim that 1MB if VGA does not exist. 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
On Thu, 2006-04-13 at 23:53 -0600, Alex Williamson wrote: I over estimated the abilities of 'hg serve', looks like it's only a single threaded server not meant for much of a load. It's running, but it only allows a single connection at a time, so if someone is doing an 'hg clone' it can be a significant delay. I'll try to setup the concurrent cgi access tomorrow. Hi, The CGI server is setup. Instead of the port 8000 server, please use this instead: http://free.linux.hp.com/~awilliam/p2m_vp_take4 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
On Wed, Apr 12, 2006 at 01:16:37PM +0800, Tian, Kevin wrote: 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. Hi Kevin. Thanks for your testing. The Tristan's log said that no page is assigned to the 0xfae area. It doesn't seem that MMIO area covers the 0xfae area. So Tristan's case is different from Alex's. MDT table must be confirmed. For Alex's case dom_fw_init() must be modified so that dom_fw_dom0_pasthrough() is called at first and then conventional memory should be mapped without overlap. 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. I agree with you. But this issues isn't specific to the P2M/VP patch. Linux VGA driver doesn't take care of the mmio base address. So it should be also modified or disabled. -- 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
From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 14:10 Hi Kevin. Thanks for your testing. The Tristan's log said that no page is assigned to the 0xfae area. It doesn't seem that MMIO area covers the 0xfae area. So Tristan's case is different from Alex's. MDT table must be confirmed. I'm jus interested that all MMIO ranges are reported by Xen to dom0, and the 0xfae area should come from real ACPI table. Why is it not captured by dom_fw_init since the latter already walks the efi memmap? 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. I agree with you. But this issues isn't specific to the P2M/VP patch. Yes, I just realized the issue and then raised it out. :-) Thanks, Kevin Linux VGA driver doesn't take care of the mmio base address. So it should be also modified or disabled. -- 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
On Wed, Apr 12, 2006 at 02:12:39PM +0800, Tian, Kevin wrote: From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 14:10 Hi Kevin. Thanks for your testing. The Tristan's log said that no page is assigned to the 0xfae area. It doesn't seem that MMIO area covers the 0xfae area. So Tristan's case is different from Alex's. MDT table must be confirmed. I'm jus interested that all MMIO ranges are reported by Xen to dom0, and the 0xfae area should come from real ACPI table. Why is it not captured by dom_fw_init since the latter already walks the efi memmap? I'm also curious. -- 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 Mercredi 12 Avril 2006 07:16, Tian, Kevin a écrit : 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. No. 0xfae0 is simply not in the memmap! I don't know why, I am asking to BIOS people. If I have a few minutes, I could try to patch the memmap to extend an entry. 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
Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit : From: Isaku Yamahata [mailto:[EMAIL PROTECTED] [...] 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. I agree with you. But this issues isn't specific to the P2M/VP patch. I don't agree with this solution. I really prefer to have warnings because it means something got wrong. domU shouldn't access to mmio. If you use a dummy page, a device driver may loop. 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
Congratulations!
That is why Kevin and I advocated many times before to suggest p2m
translation (p!=m) :-)
Can we also share the free beer?
Eddie
Magenheimer, Dan (HP Labs Fort Collins) wrote:
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.c 2006-04-10
13:17:31.0 -0600
+++ xen/xen/arch/ia64/xen/dom_fw.c 2006-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
RE: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 15:08 Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit : From: Isaku Yamahata [mailto:[EMAIL PROTECTED] [...] 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. I agree with you. But this issues isn't specific to the P2M/VP patch. I don't agree with this solution. I really prefer to have warnings because it means something got wrong. domU shouldn't access to mmio. If you use a dummy page, a device driver may loop. Either way. Currently return 0 after warning actually same as dummy page. 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][RFC][TAKE4] the P2M/VP patches
Le Mercredi 12 Avril 2006 09:07, Tian, Kevin a écrit : From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 15:08 Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit : From: Isaku Yamahata [mailto:[EMAIL PROTECTED] [...] 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. I agree with you. But this issues isn't specific to the P2M/VP patch. I don't agree with this solution. I really prefer to have warnings because it means something got wrong. domU shouldn't access to mmio. If you use a dummy page, a device driver may loop. Either way. Currently return 0 after warning actually same as dummy page. What about write accesses ? 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
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 15:20 Le Mercredi 12 Avril 2006 09:07, Tian, Kevin a écrit : From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 15:08 Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit : From: Isaku Yamahata [mailto:[EMAIL PROTECTED] [...] 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. I agree with you. But this issues isn't specific to the P2M/VP patch. I don't agree with this solution. I really prefer to have warnings because it means something got wrong. domU shouldn't access to mmio. If you use a dummy page, a device driver may loop. Either way. Currently return 0 after warning actually same as dummy page. What about write accesses ? Tristan. First, current code is taking mfn 0 as the result when mapping is not found which is more problematic like write access as you mentioned Second, mapping to a dummy page has similar effect, but no harm for write Last, the only way to prevent such io access is from guest itself, meant not compiling native drivers in. Or else there's no way for xen to handle it correctly. 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][RFC][TAKE4] the P2M/VP patches
Le Mercredi 12 Avril 2006 09:23, Tian, Kevin a écrit : From: Tristan Gingold [mailto:[EMAIL PROTECTED] [...] But this issues isn't specific to the P2M/VP patch. I don't agree with this solution. I really prefer to have warnings because it means something got wrong. domU shouldn't access to mmio. If you use a dummy page, a device driver may loop. Either way. Currently return 0 after warning actually same as dummy page. What about write accesses ? Tristan. First, current code is taking mfn 0 as the result when mapping is not found which is more problematic like write access as you mentioned Second, mapping to a dummy page has similar effect, but no harm for write Writing page 0 is harmless! Last, the only way to prevent such io access is from guest itself, meant not compiling native drivers in. Or else there's no way for xen to handle it correctly. User should disable drivers in domU. Everybody agree with that! You can also use command line options to do that. But without warnings, you don't know there are drivers enabled. 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
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年4月12日 16:02 First, current code is taking mfn 0 as the result when mapping is not found which is more problematic like write access as you mentioned Second, mapping to a dummy page has similar effect, but no harm for write Writing page 0 is harmless! It's harmless because it's trimmed down by efi memmap walker, which means it's free and no one use it. So, it's same concept to dummy page here. Last, the only way to prevent such io access is from guest itself, meant not compiling native drivers in. Or else there's no way for xen to handle it correctly. User should disable drivers in domU. Everybody agree with that! Yes, except driver domain. You can also use command line options to do that. Can cmdline disable all the native drivers, like keyboard? Previous we have different config file for xen0 and xenU, and thus unwanted drivers are removed from config file. But now xen0 and xenU share same config file, how x86 solves this issue? But without warnings, you don't know there are drivers enabled. Agree to keep warning there, but stack dump may be enabled conditionally which scares people to think something corrupted. 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][RFC][TAKE4] the P2M/VP patches
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006?4?12? 23:29 To: Tristan Gingold Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches On Wed, 2006-04-12 at 09:01 +0100, Tristan Gingold wrote: Last, the only way to prevent such io access is from guest itself, meant not compiling native drivers in. Or else there's no way for xen to handle it correctly. User should disable drivers in domU. Everybody agree with that! I don't. Xen needs to handle this better. domU I/O port space should be mapped to fault on access. Writes should be dropped and reads return -1. This is how a legacy system would behave. We don't really care about performance here, I/O port space is already slow, and this is really only meant to handle startup time probing. IMHO, it's unreasonable to ask users to disable all drivers or even try to tell them what that means. The Linux/ia64 kernel currently does a pretty good job of not blindly probing address spaces looking for hardware. I think as long as we handle I/O port space reasonably, we'll make the driver situation in domU more flexible. Thanks, Alex HASH-VTLB has already handled IO-PORT and IO-MM, HASH-VTLB records guest IO-PORT or IO-MM translation of guest, but not insert this translation into machine VHPT or machine TLB, thus, every time guest accesses IO, tlb miss happens. Now, it is up to VMM to handle guest IO operations. Thanks, Anthony -- 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 ___ 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
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][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][RFC][TAKE4] the P2M/VP patches
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. BTW, I got message about bad mp address (on FAME and on Tiger-2). Did you encounter them ? Thanks, 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 Mon, 2006-04-10 at 13:55 +0900, Isaku Yamahata wrote: I have the following ideas. I think B. or C. might be good. What do you think of them? A. record a huge region to somewhere (maybe struct arch_domain) and add region check code to lookup_domian_mpa() (and its families) for special conversion on a huge region. B. introduce a flag of super page for the P2M table. Then only a PGD (, PUD and PMD )page is needed to map such a huge page. Modify lookup_domain_mpa(), dom_fw_dom0_passthrough() and their families to be aware of super page flag. C. Don't map MMIO range at domain creation. But map it when ioremap hypercall. Maybe only small portion of the range will be used. D. other? Choice C might be a good idea from a simplicity and compactness perspective. It typically is the case that only a small portion of MMIO is actually in use. Maybe this could also facilitate driver domains as MMIO ranges could be more dynamically allocated(?). 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
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.c 2006-04-10 13:17:31.0 -0600
+++ xen/xen/arch/ia64/xen/dom_fw.c 2006-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
/* hypercall patches live here, masquerade as reserved PAL
memory */
MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB,HYPERCALL_START,HYPERCALL_END, 1);
@@ -915,6 +940,8 @@
MAKE_MD(EFI_RESERVED_TYPE,0,0,0,0);
}
+ sort(efi_memmap, i, sizeof(efi_memory_desc_t), efi_mdt_cmp, NULL);
+
bp-efi_systab = dom_pa((unsigned long) fw_mem);
bp-efi_memmap = dom_pa((unsigned long) efi_memmap);
BUG_ON(i NUM_MEM_DESCS);
___
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
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. BTW, I got message about bad mp address (on FAME and on Tiger-2). Did you encounter them ? Is its address in I/O area? Some device drivers access I/O port to check its existance. (VGA, ATA, serial...) It might cause bad mpa. Stack trace will be printed. You get Linux address 0xa00..., then you can determine which device driver caused it. -- 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
From: Alex Williamson Sent: 2006年4月8日 1:07 Hi Isaku, Great work! I'm happy to take on whatever patch load is necessary to help faciliate this effort. I'll get the header file patches into the tree. It will be important for all of us to help test and review these patches over the next few weeks to make this change happen. Agree. :-) 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][RFC][TAKE4] the P2M/VP patches
Hi Alex. I understand what's going on. (I wrote the last mail in hurry. so I didn't look the log so closely. sorry for that) (XEN) mem40: type=11, attr=0x1, range=[0x0800-0x1000) (8388608MB) Plase note that type = 11 = EFI_MEMORY_MAPPED_IO About 8TB (~= 8388608MB / 1024) is required to map this range to dom0 for the P2M conversion table. This is the reason why the xenheap is used up. Allocating from domheap instead of xenheap doesn't solve because 8TB is too huge. I didn't expect such a huge range. (BTW What is the MMIO range is used for?) Perhaps you may see dom0 boot message by skipping to map the MMIO range. If dom0 tries to do access the MMIO range, something go wrong though. dom_fw_init() =efi_memmap_walk_type(EFI_MEMORY_MAPPED_IO, dom_fw_dom0_passthrough, arg); = dom_fw_dom0_passthrough() modify this function. Maybe some special code for handling such a huge range is needed. thanks. On Sat, Apr 08, 2006 at 11:20:30AM -0600, Alex Williamson wrote: On Sat, 2006-04-08 at 13:41 +0900, Isaku Yamahata wrote: Could you try again with the following work around patch? This patch may break something, but this patch may help to track down this issue. Hi Yamata, I tried alloc_domheap_pages(NULL, 0, 0) in pgtable_quicklist_alloc(). I don't have physical access to the system right now to remove ram, instead I booted with max_addr=1G on the xen half of the append line. With that I hit a BUG in ia64_handle_reflection(). Here's the log. Thanks, Alex -- 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
On Mon, 2006-04-10 at 11:46 +0900, Isaku Yamahata wrote: (XEN) mem40: type=11, attr=0x1, range=[0x0800-0x1000) (8388608MB) Plase note that type = 11 = EFI_MEMORY_MAPPED_IO About 8TB (~= 8388608MB / 1024) is required to map this range to dom0 for the P2M conversion table. This is the reason why the xenheap is used up. Allocating from domheap instead of xenheap doesn't solve because 8TB is too huge. I didn't expect such a huge range. (BTW What is the MMIO range is used for?) Hi Yamahata, This is a 64bit MMIO space. Currently nothing really gets mapped here, but if we're trying to map these like memory, we're in trouble. As seen here, the range is huge, and it's not likely to get smaller in the future. Perhaps you may see dom0 boot message by skipping to map the MMIO range. If dom0 tries to do access the MMIO range, something go wrong though. dom_fw_init() =efi_memmap_walk_type(EFI_MEMORY_MAPPED_IO, dom_fw_dom0_passthrough, arg); = dom_fw_dom0_passthrough() modify this function. Maybe some special code for handling such a huge range is needed. Yes, for the short term we may be able to ignore this range, but we need a solution fairly soon as it's possible firmware or dom0 might choose to map cards into this MMIO space (this range is also descried in ACPI for dom0). Identity mapping of the entire uncached address space for dom0 might be sufficient until we start on driver domains. 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
On Sun, Apr 09, 2006 at 09:43:07PM -0600, Alex Williamson wrote: Maybe some special code for handling such a huge range is needed. Yes, for the short term we may be able to ignore this range, but we need a solution fairly soon as it's possible firmware or dom0 might choose to map cards into this MMIO space (this range is also descried in ACPI for dom0). Identity mapping of the entire uncached address space for dom0 might be sufficient until we start on driver domains. Thanks, I have the following ideas. I think B. or C. might be good. What do you think of them? A. record a huge region to somewhere (maybe struct arch_domain) and add region check code to lookup_domian_mpa() (and its families) for special conversion on a huge region. B. introduce a flag of super page for the P2M table. Then only a PGD (, PUD and PMD )page is needed to map such a huge page. Modify lookup_domain_mpa(), dom_fw_dom0_passthrough() and their families to be aware of super page flag. C. Don't map MMIO range at domain creation. But map it when ioremap hypercall. Maybe only small portion of the range will be used. D. other? -- 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
On Sat, 2006-04-08 at 13:41 +0900, Isaku Yamahata wrote: Could you try again with the following work around patch? This patch may break something, but this patch may help to track down this issue. Hi Yamata, I tried alloc_domheap_pages(NULL, 0, 0) in pgtable_quicklist_alloc(). I don't have physical access to the system right now to remove ram, instead I booted with max_addr=1G on the xen half of the append line. With that I hit a BUG in ia64_handle_reflection(). Here's the log. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab (XEN) Console output is synchronous. (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) efi.trim_top: ignoring 4KB of memory at 0x0 due to granule hole at 0x0 (XEN) efi.trim_top: ignoring 636KB of memory at 0x1000 due to granule hole at 0x0 (XEN) efi.trim_bottom: ignoring 15360KB of memory at 0x10 due to granule hole at 0x0 (XEN) ready to move Dom0 to 0x800 with len e30160...ready to move initrd to 0x8e34000 with len 0...Done (XEN) find_memory: efi_memmap_walk returns max_page=fecb (XEN) find_memory: last granule reserved for dom0; xen max_page=f800 (XEN) mem00: type=4, attr=0x8, range=[0x-0x) (0MB) (XEN) mem01: type=7, attr=0x8, range=[0x1000-0x1000) (0MB) (XEN) mem02: type=11, attr=0x3, range=[0x000a-0x000c) (0MB) (XEN) mem03: type=5, attr=0x8001, range=[0x000c-0x0010) (0MB) (XEN) mem04: type=7, attr=0x8, range=[0x0100-0x0400) (48MB) (XEN) mem05: type=2, attr=0x8, range=[0x0400-0x04103000) (1MB) (XEN) mem06: type=7, attr=0x8, range=[0x04103000-0x3f5e4000) (948MB) (XEN) mem07: type=5, attr=0x8008, range=[0x3f5e4000-0x3fac) (4MB) (XEN) mem08: type=13, attr=0x8008, range=[0x3fac-0x3fb0) (0MB) (XEN) mem09: type=7, attr=0x8, range=[0x3fb0-0x3fb06000) (0MB) (XEN) mem10: type=4, attr=0x8, range=[0x3fb06000-0x3fb2c000) (0MB) (XEN) mem11: type=9, attr=0x8, range=[0x3fb2c000-0x3fb38000) (0MB) (XEN) mem12: type=6, attr=0x8008, range=[0x3fb38000-0x4000) (4MB) (XEN) mem13: type=11, attr=0x1, range=[0x8000-0xfe00) (2016MB) (XEN) mem14: type=11, attr=0x8001, range=[0xfed0-0x0001) (19MB) (XEN) mem15: type=7, attr=0x8, range=[0x0001-0x00027fffe000) (6143MB) (XEN) mem16: type=6, attr=0x8008, range=[0x00027fffe000-0x00028000) (0MB) (XEN) mem17: type=7, attr=0x8, range=[0x00404000-0x0040fcb72000) (3019MB) (XEN) mem18: type=2, attr=0x8, range=[0x0040fcb72000-0x0040fd9a3000) (14MB) (XEN) mem19: type=7, attr=0x8, range=[0x0040fd9a3000-0x0040fdf7c000) (5MB) (XEN) mem20: type=2, attr=0x8, range=[0x0040fdf7c000-0x0040fef9e000) (16MB) (XEN) mem21: type=7, attr=0x8, range=[0x0040fef9e000-0x0040fef9f000) (0MB) (XEN) mem22: type=1, attr=0x8, range=[0x0040fef9f000-0x0040ff00) (0MB) (XEN) mem23: type=7, attr=0x8, range=[0x0040ff00-0x0040ff2f) (2MB) (XEN) mem24: type=4, attr=0x8, range=[0x0040ff2f-0x0040ff801000) (5MB) (XEN) mem25: type=7, attr=0x8, range=[0x0040ff801000-0x0040ff802000) (0MB) (XEN) mem26: type=4, attr=0x8, range=[0x0040ff802000-0x0040ff808000) (0MB) (XEN) mem27: type=7, attr=0x8, range=[0x0040ff808000-0x0040ff80a000) (0MB) (XEN) mem28: type=4, attr=0x8, range=[0x0040ff80a000-0x0040ff80e000) (0MB) (XEN) mem29: type=7, attr=0x8, range=[0x0040ff80e000-0x0040ff816000) (0MB) (XEN) mem30: type=4, attr=0x8, range=[0x0040ff816000-0x0040ff9fc000) (1MB) (XEN) mem31: type=7, attr=0x8, range=[0x0040ff9fc000-0x0040ff9fd000) (0MB) (XEN) mem32: type=4, attr=0x8, range=[0x0040ff9fd000-0x0040ffa0) (0MB) (XEN) mem33: type=7, attr=0x8, range=[0x0040ffa0-0x0040ffd6a000) (3MB) (XEN) mem34: type=5, attr=0x8008, range=[0x0040ffd6a000-0x0040ffda6000) (0MB) (XEN) mem35: type=3, attr=0x8, range=[0x0040ffda6000-0x0040ffe0) (0MB) (XEN) mem36: type=7, attr=0x8, range=[0x0040ffe0-0x0040ffe12000) (0MB) (XEN) mem37: type=5, attr=0x8008, range=[0x0040ffe12000-0x0040ffe8) (0MB) (XEN) mem38: type=7, attr=0x8, range=[0x0040ffe8-0x0040fffc) (1MB) (XEN) mem39: type=6, attr=0x8008, range=[0x0040fffc-0x0041) (0MB) (XEN) mem40: type=11, attr=0x1, range=[0x0800-0x1000) (8388608MB) (XEN) mem41: type=12, attr=0x8001, range=[0x0003fc00-0x0004) (64MB) (XEN) Before heap_start: f4102598 (XEN) After heap_start: f4108000 (XEN) Init boot pages: 0x100 -
RE: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
From: Isaku Yamahata
Sent: 2006年4月7日 12:16
* summary
With these patches, dom0, domU boot and vnif, balloon works.
Great progress.
9504:c50a58f28451_fix_grant_entry_t_frame.patch
change the type of grant_entry::frame from uint32_t to
unsigned long.
In theory IA64 supports 50 bits physical address,
36 bits is needed with 16KBytes page size.
As Kevin pointed out xen/ia64 can work fine for several years
without this patch.
If this patch is rejected, we can go without this patch.
At least one reason to accept this patch is that current grant_table.h
itself is even using both. Mfn of gnttab_transfer is defined as unsigned
long, however frames of other structures for uint32_t. You may push
as a cleanup reason.
9519:d6c77b041a70_page_to_bus.patch
introduce page_to_bus() and used for pci-dma-xen.c and
swiotlb.c
On xen/ia64 with the P2M/VP model pseudo physical address
is fully
virtualized so it defines as
xen_features(XENFEAT_auto_translated_physmap) = 1.
In this case page_to_phys(sg[i].page) should return pseudo
physical
address like pfn_to_mfn() and its families.
However dma is not virtualized, it can't be used for
pci-dma-xen.c,
swiotlb.c.
If this patch is rejected, we can introduce xenLinux/ia64-specific
pci-dma-xen.c swiotlb.c. But such a divergence is not desirable.
Seems reasonable. Just one small comment, since xen/ia64 currently
depends on auto_translated mode, is it possible to make your solution
common, instead of only special case for xen/ia64? By your patch, x86
still can't take auto_translated mode as a backend. Not sure whether
easy/clean to make it, maybe a submode of auto_translated?
9526:f93f01f21f37_arch_specific_xen_feature.patch
allow arch to define arch-specific xen_feature()
Xen/ia64 with the P2M/VP model define
xen_features(XENFEAT_auto_translated_physmap) = 1.
It is NOT run-time feature. It is desirable to code it explicitly
like
static inline int
xen_feature(int flag)
{
switch (flag)
{
case XENFEAT_auto_translated_physmap:
return 1;
default:
return xen_features[flag];
}
/* NOTREACHED */
}
This patch allows it.
Does this patch only save one hypercall overhead? We can always
tell guest the auto_translated bit is true when guest hypercalls to
query feature bits into xen_feature array.
* proposal for the merge of the P2M/VP patches
It was decided that the P2M/VP patches would go to
xen-ia64-unstable-Intel.hg at first and then would be pulled up to
xen-ia64-unstable.hg once it was stabilized.
However the P2M/VP patches have become too big.
(We didn't expect at that time, did we?)
It might be very difficult to merge at a time, I think.
So I propose merging gradually reducing the patch size.
The P2M/VP patches have a compile-time option.
The option is disabled by default at first.
Yes, I think it's good for your patches to be in xen-ia64-unstable
gradually with compile option there. This is a typical way how a
complete feature is added into mainstream, like recent supervisor
mode for example. Yes, once after getting community consensus. :-)
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][RFC][TAKE4] the P2M/VP patches
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: 2006年4月7日 15:48
I'll post a quick hack patch for xenLinux/x86 (but only compile-test)
when I post this patch.
A new conversion function needs to be introduced.
unsigned long pfn_to_mfn_for_dma(unsigned long pfn)
{
if (xen_feature(XENFEAT_auto_translated_dmaaddr))
return pfn;
return real_pfn_to_mfn(pfn);
}
unsigned long pfn_to_mfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_auto_translated_physmap))
return pfn;
return real_pfn_to_mfn(pfn);
}
OK.
Does this patch only save one hypercall overhead? We can always
tell guest the auto_translated bit is true when guest hypercalls to
query feature bits into xen_feature array.
No.
I agree that we can go without this patch by telling the bit always 1.
The reasons why I wrote this patch are as follows
- It is more explicit than telling auto_translated bit always 1.
Perhaps code readers expect that the auto_translated feature
can be determined at run-time even for xen/ia64, not requirement.
This is only a readability issue.
Telling auto_translated bit 1 makes code harder-to-read a bit.
- Compiler can optimize better.
Maybe I'm not clear here. You can see from setup_xen_features
where a hypercall is issued to query what on earth this domain is
configured with. That feature info can be passed in from config file.
So I think even xen/ia64 wants to hardcode auto_translated bit as 1,
it's better to do within xen with xenlinux inferface unchanged to query.
Anyway, we don't want to eliminate future possibility that dom0 may
also see physmap directly for performance. :-) But yes, seems this
feature need to be queried earlier which seems difficult for current
xen/ia64 model. So it may be better to hardcode xen_features array
for now.
How do you think?
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][RFC][TAKE4] the P2M/VP patches
On Fri, Apr 07, 2006 at 03:57:30PM +0800, Tian, Kevin wrote: Does this patch only save one hypercall overhead? We can always tell guest the auto_translated bit is true when guest hypercalls to query feature bits into xen_feature array. No. I agree that we can go without this patch by telling the bit always 1. The reasons why I wrote this patch are as follows - It is more explicit than telling auto_translated bit always 1. Perhaps code readers expect that the auto_translated feature can be determined at run-time even for xen/ia64, not requirement. This is only a readability issue. Telling auto_translated bit 1 makes code harder-to-read a bit. - Compiler can optimize better. Maybe I'm not clear here. You can see from setup_xen_features where a hypercall is issued to query what on earth this domain is configured with. That feature info can be passed in from config file. So I think even xen/ia64 wants to hardcode auto_translated bit as 1, it's better to do within xen with xenlinux inferface unchanged to query. Anyway, we don't want to eliminate future possibility that dom0 may also see physmap directly for performance. :-) But yes, seems this feature need to be queried earlier which seems difficult for current xen/ia64 model. So it may be better to hardcode xen_features array for now. How do you think? In fact I wondered that this patch was acceptable. I guess that xen/x86 people will be against this patch saying similar things. This patch is not important, just for my preference. I drop this patch. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Software lockup (was Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches)
Hi, a side question: [...] - 9536:357ffc54d5ca_make_vhpt_64kb.patch Without this patch linux software lock up detection is triggered. This is a temporal work around. In fact it is very easy to trigger the software lock up: pause and unpause a domain. Is software lockup enabled on xenlinux/x86 ? 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 Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata wrote: As the first step I propose merging the patches which import header files. It is trivial to import those header files. In fact this might increase the repository maintainer's (Alex) task. But those header files are quite stable, so I hope importing the files won't increase the task. Concretely I propose merging the following patches. 9510:60247c40232d_move_linux_efi_h_to_linux_xen_linux_efi_h.patch 9511:46a10ae8d89e_dom0_vp_model_xen_side_README_orig_efi_h.patch 9513:c7021ef2e2be_import_io_h.patch 9514:b921fd53d768_import_page_h.patch 9515:1959454246ca_import_pgalloc_h.patch 9516:faffc27d897c_import_dma_mapping_h.patch 9517:b58eb5f96c36_import_machvec_h.patch 9518:04b6d3ea75c9_import_agp_h.patch Hi Isaku, Great work! I'm happy to take on whatever patch load is necessary to help faciliate this effort. I'll get the header file patches into the tree. It will be important for all of us to help test and review these patches over the next few weeks to make this change happen. I tried this patch set on xen-ia64-unstable tip (cset 9493), there were a couple trivial rejects, but it built properly. However, when I try it on an HP zx6000 system, it fails with the output below. I've deconfigured the 2nd CPU and reduced the system memory to 1GB to avoid the strange memory layout of zx1 systems. Any suggestions? Thanks, Alex -- Alex Williamson HP Linux Open Source Lab Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 3.4.6 20060122 (prerelease) (Debian 3.4.5-2)) Fri Apr 7 10:09:23 MDT 2006 Latest ChangeSet: Thu Apr 6 15:51:59 2006 -0600 9493:cc94ab1e0de0 (XEN) Console output is synchronous. (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) efi.trim_top: ignoring 4KB of memory at 0x0 due to granule hole at 0x0 (XEN) efi.trim_top: ignoring 636KB of memory at 0x1000 due to granule hole at 0x0 (XEN) efi.trim_bottom: ignoring 15360KB of memory at 0x10 due to granule hole at 0x0 (XEN) ready to move Dom0 to 0x800 with len e30160...ready to move initrd to 0x8e34000 with len 0...Done (XEN) find_memory: efi_memmap_walk returns max_page=fecb (XEN) find_memory: last granule reserved for dom0; xen max_page=f800 (XEN) mem00: type=4, attr=0x8, range=[0x-0x) (0MB) (XEN) mem01: type=7, attr=0x8, range=[0x1000-0x1000) (0MB) (XEN) mem02: type=11, attr=0x3, range=[0x000a-0x000c) (0MB) (XEN) mem03: type=5, attr=0x8001, range=[0x000c-0x0010) (0MB) (XEN) mem04: type=7, attr=0x8, range=[0x0100-0x0400) (48MB) (XEN) mem05: type=2, attr=0x8, range=[0x0400-0x04103000) (1MB) (XEN) mem06: type=7, attr=0x8, range=[0x04103000-0x3c154000) (896MB) (XEN) mem07: type=2, attr=0x8, range=[0x3c154000-0x3cf85000) (14MB) (XEN) mem08: type=7, attr=0x8, range=[0x3cf85000-0x3d55e000) (5MB) (XEN) mem09: type=2, attr=0x8, range=[0x3d55e000-0x3e58) (16MB) (XEN) mem10: type=7, attr=0x8, range=[0x3e58-0x3e581000) (0MB) (XEN) mem11: type=1, attr=0x8, range=[0x3e581000-0x3e5e2000) (0MB) (XEN) mem12: type=7, attr=0x8, range=[0x3e5e2000-0x3e854000) (2MB) (XEN) mem13: type=4, attr=0x8, range=[0x3e854000-0x3ec01000) (3MB) (XEN) mem14: type=7, attr=0x8, range=[0x3ec01000-0x3ec56000) (0MB) (XEN) mem15: type=4, attr=0x8, range=[0x3ec56000-0x3ec5e000) (0MB) (XEN) mem16: type=7, attr=0x8, range=[0x3ec5e000-0x3ec6) (0MB) (XEN) mem17: type=4, attr=0x8, range=[0x3ec6-0x3ec64000) (0MB) (XEN) mem18: type=7, attr=0x8, range=[0x3ec64000-0x3ec6c000) (0MB) (XEN) mem19: type=4, attr=0x8, range=[0x3ec6c000-0x3eca6000) (0MB) (XEN) mem20: type=7, attr=0x8, range=[0x3eca6000-0x3eca7000) (0MB) (XEN) mem21: type=4, attr=0x8, range=[0x3eca7000-0x3efe2000) (3MB) (XEN) mem22: type=7, attr=0x8, range=[0x3efe2000-0x3f34c000) (3MB) (XEN) mem23: type=5, attr=0x8008, range=[0x3f34c000-0x3f388000) (0MB) (XEN) mem24: type=3, attr=0x8, range=[0x3f388000-0x3f3e2000) (0MB) (XEN) mem25: type=7, attr=0x8, range=[0x3f3e2000-0x3f3f4000) (0MB) (XEN) mem26: type=5, attr=0x8008, range=[0x3f3f4000-0x3f462000) (0MB) (XEN) mem27: type=7, attr=0x8, range=[0x3f462000-0x3f5a2000) (1MB) (XEN) mem28: type=6, attr=0x8008, range=[0x3f5a2000-0x3f5e4000) (0MB) (XEN) mem29: type=5, attr=0x8008, range=[0x3f5e4000-0x3fac) (4MB) (XEN) mem30: type=13, attr=0x8008, range=[0x3fac-0x3fb0) (0MB) (XEN)
Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
Hi Alex.
On Fri, Apr 07, 2006 at 11:06:53AM -0600, Alex Williamson wrote:
Great work! I'm happy to take on whatever patch load is necessary to
help faciliate this effort. I'll get the header file patches into the
tree. It will be important for all of us to help test and review these
patches over the next few weeks to make this change happen.
I'm glad to hear that.
Then I'll start to pushing merging patches soon.
Perhaps from the next monday or tuesday.
I tried this patch set on xen-ia64-unstable tip (cset 9493), there
were a couple trivial rejects, but it built properly. However, when I
try it on an HP zx6000 system, it fails with the output below. I've
deconfigured the 2nd CPU and reduced the system memory to 1GB to avoid
the strange memory layout of zx1 systems. Any suggestions? Thanks,
from the log message
(XEN) Cannot handle page request order 0!
This message means that the xen heap memory is used up and
alloc_xenheap_pages() failed.
However you wisely limited total memory to 1GB,
thus page frame table size is 2MB and mpt_table size is 512KB.
So it's the key to know who used up the xen heap.
I guess pgtable_quicklist_alloc() might be a culprit.
Could you try again with the following work around patch?
This patch may break something, but this patch may help
to track down this issue.
--- xen-ia64-unstable.hg/xen/arch/ia64/xen/xenmisc.c2006-04-06
22:25:41.0 +0900
+++ xen-ia64-unstable.hg/xen/arch/ia64/xen/xenmisc.c_workaround 2006-04-08
13:23:05.0 +0900
@@ -161,7 +161,8 @@ void __free_pages(struct page_info *page
void *pgtable_quicklist_alloc(void)
{
void *p;
-p = alloc_xenheap_pages(0);
+//p = alloc_xenheap_pages(0);
+ p = alloc_domheap_pages(NULL);
if (p)
clear_page(p);
return p;
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
