From: Gerd Hoffmann <kraxel@suse.de>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: access shared_info?
Date: Wed, 07 Jun 2006 17:53:26 +0200 [thread overview]
Message-ID: <4486F676.6080301@suse.de> (raw)
In-Reply-To: <20b4659f13d0ed8c0ee5d23d93579b4c@cl.cam.ac.uk>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
> Even if you could get address of shared_info, you can't map it into user
> space without some kernel hacking to make that possible (/dev/mem can
> only map I/O memory when running on Xen).
Ok, different attack ;)
How about the attached patch? It makes /proc/iomem under xen dom0 look
like on native hardware. Also for domU it has some sensible values then
instead of being empty.
cheers,
Gerd
--
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg
[-- Attachment #2: iomem.diff --]
[-- Type: text/x-patch, Size: 3485 bytes --]
diff -r c191c649cdb3 linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c
--- a/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c Tue Jun 6 09:25:59 2006
+++ b/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c Wed Jun 7 17:48:10 2006
@@ -1352,10 +1352,23 @@
* Request address space for all standard RAM and ROM resources
* and also for regions reported as reserved by the e820.
*/
+
+static void __init register_kernel_ressources(struct resource *res)
+{
+ /*
+ * We don't know which RAM region contains kernel data,
+ * so we try it repeatedly and let the resource manager
+ * test it.
+ */
+ request_resource(res, &code_resource);
+ request_resource(res, &data_resource);
+#ifdef CONFIG_KEXEC
+ request_resource(res, &crashk_res);
+#endif
+}
+
static void __init
-legacy_init_iomem_resources(struct e820entry *e820, int nr_map,
- struct resource *code_resource,
- struct resource *data_resource)
+legacy_init_iomem_resources(struct e820entry *e820, int nr_map)
{
int i;
@@ -1378,21 +1391,23 @@
res->end = res->start + e820[i].size - 1;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
request_resource(&iomem_resource, res);
-#ifndef CONFIG_XEN
- if (e820[i].type == E820_RAM) {
- /*
- * We don't know which RAM region contains kernel data,
- * so we try it repeatedly and let the resource manager
- * test it.
- */
- request_resource(res, code_resource);
- request_resource(res, data_resource);
-#ifdef CONFIG_KEXEC
- request_resource(res, &crashk_res);
-#endif
- }
-#endif
- }
+ if (e820[i].type == E820_RAM)
+ register_kernel_ressources(res);
+ }
+}
+
+static void __init
+domU_init_iomem_resources(void)
+{
+ struct resource *res;
+
+ res = alloc_bootmem_low(sizeof(struct resource));
+ res->name = "System RAM";
+ res->start = 0;
+ res->end = (max_pfn * PAGE_SIZE) - 1;
+ res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ request_resource(&iomem_resource, res);
+ register_kernel_ressources(res);
}
/*
@@ -1460,8 +1475,10 @@
int i;
/* Nothing to do if not running in dom0. */
- if (!(xen_start_info->flags & SIF_INITDOMAIN))
+ if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
+ domU_init_iomem_resources();
return;
+ }
#ifdef CONFIG_XEN
machine_e820 = alloc_bootmem_low_pages(PAGE_SIZE);
@@ -1471,14 +1488,12 @@
BUG_ON(HYPERVISOR_memory_op(XENMEM_machine_memory_map, &memmap));
- legacy_init_iomem_resources(machine_e820, memmap.nr_entries,
- &code_resource, &data_resource);
+ legacy_init_iomem_resources(machine_e820, memmap.nr_entries);
#else
if (efi_enabled)
efi_initialize_iomem_resources(&code_resource, &data_resource);
else
- legacy_init_iomem_resources(e820.map, e820.nr_map,
- &code_resource, &data_resource);
+ legacy_init_iomem_resources(e820.map, e820.nr_map);
#endif
/* EFI systems may still have VGA */
@@ -1698,11 +1713,10 @@
init_mm.brk = (PFN_UP(__pa(xen_start_info->pt_base)) +
xen_start_info->nr_pt_frames) << PAGE_SHIFT;
- /* XEN: This is nonsense: kernel may not even be contiguous in RAM. */
- /*code_resource.start = virt_to_phys(_text);*/
- /*code_resource.end = virt_to_phys(_etext)-1;*/
- /*data_resource.start = virt_to_phys(_etext);*/
- /*data_resource.end = virt_to_phys(_edata)-1;*/
+ code_resource.start = virt_to_phys(_text);
+ code_resource.end = virt_to_phys(_etext)-1;
+ data_resource.start = virt_to_phys(_etext);
+ data_resource.end = virt_to_phys(_edata)-1;
parse_cmdline_early(cmdline_p);
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2006-06-07 15:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-07 13:28 access shared_info? Gerd Hoffmann
2006-06-07 13:48 ` Keir Fraser
2006-06-07 15:53 ` Gerd Hoffmann [this message]
2006-06-07 16:04 ` Keir Fraser
2006-06-07 16:27 ` Gerd Hoffmann
2006-06-07 16:47 ` Keir Fraser
2006-06-07 16:59 ` Gerd Hoffmann
2006-06-07 17:27 ` Gerd Hoffmann
2006-06-07 21:55 ` Chris Wright
2006-06-08 7:32 ` Keir Fraser
2006-06-09 13:44 ` Gerd Hoffmann
2006-06-09 13:59 ` Ian Campbell
2006-06-09 14:16 ` Gerd Hoffmann
2006-06-09 14:35 ` Keir Fraser
2006-06-09 17:34 ` Chris Wright
2006-06-09 17:23 ` Chris Wright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4486F676.6080301@suse.de \
--to=kraxel@suse.de \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.