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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> 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_resourceWell, 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* 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); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel