access shared_info?

access shared_info?

[Gerd Hoffmann]

  Hi,

How can I access the shared_info page for my own domain from domU
userspace?  Seems dom0 ops are completely disabled for domUs, even for
domid == DOMID_SELF.  I need shared_info->arch.max_pfn ...

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: access shared_info?

[Keir Fraser]

On 7 Jun 2006, at 14:28, Gerd Hoffmann wrote:

> How can I access the shared_info page for my own domain from domU
> userspace?  Seems dom0 ops are completely disabled for domUs, even for
> domid == DOMID_SELF.  I need shared_info->arch.max_pfn ...

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).

  -- Keir

Re: access shared_info?

[Gerd Hoffmann]

[-- 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

Re: access shared_info?

[Keir Fraser]

On 7 Jun 2006, at 16:53, Gerd Hoffmann wrote:

> 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.

Plausible, perhaps with cleanup (e.g., why change the prototype of 
legacy_init_iomem_resource and remove non-Xen code, increasing the diff 
against native?).

  -- Keir

Re: access shared_info?

[Gerd Hoffmann]

>> 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.
> 
> Plausible, perhaps with cleanup (e.g., why change the prototype of
> legacy_init_iomem_resource

Well, there is no point in carring around those two arguments.  It's not
needed, and the third one (crash kernel area) isn't passed though
anyway.  So while touching it anyway I've dropped them as cleanup.  Not
exactly xen-related, I can try to push that upstream too ;)

> and remove non-Xen code, increasing the diff
> against native?).

Where is non-xen code removed?

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: access shared_info?

[Keir Fraser]

On 7 Jun 2006, at 17:27, Gerd Hoffmann wrote:

>> Plausible, perhaps with cleanup (e.g., why change the prototype of
>> legacy_init_iomem_resource
>
> Well, there is no point in carring around those two arguments.  It's 
> not
> needed, and the third one (crash kernel area) isn't passed though
> anyway.  So while touching it anyway I've dropped them as cleanup.  Not
> exactly xen-related, I can try to push that upstream too ;)
>
>> and remove non-Xen code, increasing the diff
>> against native?).
>
> Where is non-xen code removed?

Oh, I see it's moved to a new function. I guess that's okay, although 
couldn't you fake up an e820 map and call legacy_init_iomem_resource on 
the domU path, rather than having to pull code out into a new function? 
Does this patch change behaviour for dom0 at all? I think /proc/iomem 
already looks like native there? Also the patch will need to include 
x86/64 too.

   -- Keir

Re: access shared_info?

[Gerd Hoffmann]

> Oh, I see it's moved to a new function. I guess that's okay, although
> couldn't you fake up an e820 map and call legacy_init_iomem_resource on
> the domU path, rather than having to pull code out into a new function?

Should work equally well, yes.

> Does this patch change behaviour for dom0 at all? I think /proc/iomem
> already looks like native there?

The kernel code and kernel data regions are initialized and registered now.

> Also the patch will need to include
> x86/64 too.

I'll have a look.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: access shared_info?

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

Keir Fraser wrote:
> Oh, I see it's moved to a new function. I guess that's okay, although
> couldn't you fake up an e820 map and call legacy_init_iomem_resource on
> the domU path, rather than having to pull code out into a new function?
> Does this patch change behaviour for dom0 at all? I think /proc/iomem
> already looks like native there? Also the patch will need to include
> x86/64 too.

new version attached.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

[-- Attachment #2: iomem.diff --]
[-- Type: text/x-patch, Size: 3702 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 19:24:19 2006
@@ -1378,7 +1378,6 @@
 		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,
@@ -1391,7 +1390,6 @@
 			request_resource(res, &crashk_res);
 #endif
 		}
-#endif
 	}
 }
 
@@ -1460,8 +1458,16 @@
 	int	      i;
 
 	/* Nothing to do if not running in dom0. */
-	if (!(xen_start_info->flags & SIF_INITDOMAIN))
+	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
+		struct e820entry domU_e820 = {
+			.addr = 0,
+			.size = max_pfn << PAGE_SHIFT,
+			.type = E820_RAM,
+		};
+		legacy_init_iomem_resources(&domU_e820, 1,
+					    &code_resource, &data_resource);
 		return;
+	}
 
 #ifdef CONFIG_XEN
 	machine_e820 = alloc_bootmem_low_pages(PAGE_SIZE);
@@ -1698,11 +1704,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);
 
diff -r c191c649cdb3 linux-2.6-xen-sparse/arch/x86_64/kernel/e820-xen.c
--- a/linux-2.6-xen-sparse/arch/x86_64/kernel/e820-xen.c	Tue Jun  6 09:25:59 2006
+++ b/linux-2.6-xen-sparse/arch/x86_64/kernel/e820-xen.c	Wed Jun  7 19:24:19 2006
@@ -44,9 +44,7 @@
  */
 unsigned long end_user_pfn = MAXMEM>>PAGE_SHIFT;  
 
-#ifndef CONFIG_XEN
 extern struct resource code_resource, data_resource;
-#endif
 
 /* Check for some hardcoded bad areas that early boot is not allowed to touch */ 
 static inline int bad_addr(unsigned long *addrp, unsigned long size)
@@ -251,8 +249,7 @@
 		res->end = res->start + e820[i].size - 1;
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		request_resource(&iomem_resource, res);
-#ifndef CONFIG_XEN
-		if (e820.map[i].type == E820_RAM) {
+		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
@@ -264,7 +261,6 @@
 			request_resource(res, &crashk_res);
 #endif
 		}
-#endif
 	}
 }
 
diff -r c191c649cdb3 linux-2.6-xen-sparse/arch/x86_64/kernel/setup-xen.c
--- a/linux-2.6-xen-sparse/arch/x86_64/kernel/setup-xen.c	Tue Jun  6 09:25:59 2006
+++ b/linux-2.6-xen-sparse/arch/x86_64/kernel/setup-xen.c	Wed Jun  7 19:24:19 2006
@@ -692,12 +692,10 @@
 	init_mm.end_data = (unsigned long) &_edata;
 	init_mm.brk = (unsigned long) &_end;
 
-#ifndef CONFIG_XEN
 	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;
-#endif
 
 	parse_cmdline_early(cmdline_p);
 
@@ -937,6 +935,13 @@
 		BUG_ON(HYPERVISOR_memory_op(XENMEM_machine_memory_map, &memmap));
 
 		e820_reserve_resources(machine_e820, memmap.nr_entries);
+	} else {
+		struct e820entry domU_e820 = {
+			.addr = 0,
+			.size = max_pfn << PAGE_SHIFT,
+			.type = E820_RAM,
+		};
+		e820_reserve_resources(&domU_e820, 1);
 	}
 #elif !defined(CONFIG_XEN)
 	probe_roms();

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: access shared_info?

[Chris Wright]

* Gerd Hoffmann (kraxel@suse.de) wrote:
> Keir Fraser wrote:
> > Oh, I see it's moved to a new function. I guess that's okay, although
> > couldn't you fake up an e820 map and call legacy_init_iomem_resource on
> > the domU path, rather than having to pull code out into a new function?
> > Does this patch change behaviour for dom0 at all? I think /proc/iomem
> > already looks like native there? Also the patch will need to include
> > x86/64 too.
> 
> new version attached.

Might want to double check against linux-2.6.tip-xen, as that code has
changed a bit since 2.6.16.

> 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 19:24:19 2006
> @@ -1378,7 +1378,6 @@
>  		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,
> @@ -1391,7 +1390,6 @@
>  			request_resource(res, &crashk_res);
>  #endif
>  		}
> -#endif
>  	}
>  }
>  
> @@ -1460,8 +1458,16 @@
>  	int	      i;
>  
>  	/* Nothing to do if not running in dom0. */
> -	if (!(xen_start_info->flags & SIF_INITDOMAIN))
> +	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> +		struct e820entry domU_e820 = {
> +			.addr = 0,
> +			.size = max_pfn << PAGE_SHIFT,
> +			.type = E820_RAM,
> +		};

Or just do this during normal setup, then it is the base e820 map.  I
believe it's already done isn't it?

		memmap.nr_entries = 1;
		map[0].addr = 0ULL;
		map[0].size = xen_start_info->nr_pages << PAGE_SHIFT;
		/* 8MB slack (to balance backend allocations). */
		map[0].size += 8 << 20;
		map[0].type = E820_RAM;
...
	BUG_ON(copy_e820_map(map, (char)memmap.nr_entries) < 0);

Re: access shared_info?

[Keir Fraser]

On 7 Jun 2006, at 22:55, Chris Wright wrote:

>>  	/* Nothing to do if not running in dom0. */
>> -	if (!(xen_start_info->flags & SIF_INITDOMAIN))
>> +	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
>> +		struct e820entry domU_e820 = {
>> +			.addr = 0,
>> +			.size = max_pfn << PAGE_SHIFT,
>> +			.type = E820_RAM,
>> +		};
>
> Or just do this during normal setup, then it is the base e820 map.  I
> believe it's already done isn't it?
>
> 		memmap.nr_entries = 1;
> 		map[0].addr = 0ULL;
> 		map[0].size = xen_start_info->nr_pages << PAGE_SHIFT;
> 		/* 8MB slack (to balance backend allocations). */
> 		map[0].size += 8 << 20;
> 		map[0].type = E820_RAM;
> ...
> 	BUG_ON(copy_e820_map(map, (char)memmap.nr_entries) < 0);

Does the existing e820-faking code run early enough to be able to use 
max_pfn?

  -- Keir

Re: access shared_info?

[Gerd Hoffmann]

> 
> Or just do this during normal setup, then it is the base e820 map.  I
> believe it's already done isn't it?
> 
> 		memmap.nr_entries = 1;
> 		map[0].addr = 0ULL;
> 		map[0].size = xen_start_info->nr_pages << PAGE_SHIFT;
> 		/* 8MB slack (to balance backend allocations). */
> 		map[0].size += 8 << 20;
> 		map[0].type = E820_RAM;

x86_64 only, seems there are quite some differences in e820 handling ...

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: access shared_info?

[Ian Campbell]

On Fri, 2006-06-09 at 15:44 +0200, Gerd Hoffmann wrote:
> > 
> > Or just do this during normal setup, then it is the base e820 map.  I
> > believe it's already done isn't it?
> > 
> > 		memmap.nr_entries = 1;
> > 		map[0].addr = 0ULL;
> > 		map[0].size = xen_start_info->nr_pages << PAGE_SHIFT;
> > 		/* 8MB slack (to balance backend allocations). */
> > 		map[0].size += 8 << 20;
> > 		map[0].type = E820_RAM;
> 
> x86_64 only, seems there are quite some differences in e820 handling ...

The same code is in arch/x86_64/kernel/e820-xen.c and
include/asm-i386/mach-xen/setup_arch_post.h

The x86_64 code has diverged more from native than i386 in this area, it
would nice to reign it back in.

Ian.

Re: access shared_info?

[Gerd Hoffmann]

Ian Campbell wrote:
> The same code is in arch/x86_64/kernel/e820-xen.c and
> include/asm-i386/mach-xen/setup_arch_post.h
> 
> The x86_64 code has diverged more from native than i386 in this area, it
> would nice to reign it back in.

What is best to send patches against?  xen-unstable?  Or better linux-tip?

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: access shared_info?

[Keir Fraser]

On 9 Jun 2006, at 15:16, Gerd Hoffmann wrote:

>> The same code is in arch/x86_64/kernel/e820-xen.c and
>> include/asm-i386/mach-xen/setup_arch_post.h
>>
>> The x86_64 code has diverged more from native than i386 in this area, 
>> it
>> would nice to reign it back in.
>
> What is best to send patches against?  xen-unstable?  Or better 
> linux-tip?

If you're looking to unify with your previous e820-faking patch: you 
can't. One is created before max_pfn is known (and is used by default 
to work out what max_pfn should be). The one you added depends on 
knowing max_pfn.

  -- Keir

Re: access shared_info?

[Chris Wright]

* Gerd Hoffmann (kraxel@suse.de) wrote:
> Ian Campbell wrote:
> > The same code is in arch/x86_64/kernel/e820-xen.c and
> > include/asm-i386/mach-xen/setup_arch_post.h
> > 
> > The x86_64 code has diverged more from native than i386 in this area, it
> > would nice to reign it back in.
> 
> What is best to send patches against?  xen-unstable?  Or better linux-tip?

Depends.  For anything you want in the 2.6.16 based tree, xen-unstable
(that will eventually get pulled into linux-2.6.tip-xen).  For anything
that's specific to the new tree, against tip-xen.

thanks,
-chris

Re: access shared_info?

[Chris Wright]

* Keir Fraser (Keir.Fraser@cl.cam.ac.uk) wrote:
> If you're looking to unify with your previous e820-faking patch: you 
> can't. One is created before max_pfn is known (and is used by default 
> to work out what max_pfn should be). The one you added depends on 
> knowing max_pfn.

I don't think that's an issue.  The max_pfn is calculated from the first
e820 map, but it's already been truncated by command line.  So by the
time we get to setting up iomem (and the kernel code and data that Gerd
is after), the e820 map has a final E820_RAM mapping that ends at
max_pfn.  I suspect the end result in /proc/iomem would be the same.

thanks,
-chris