Xen devel - Mar 2005 - Is machine_to_phys_mapping a 4MB ''superpage''?

hi,

The machine_to_phys_mapping table is mapped permanently at 0xFC000000 
(on x86-32). I would like to experiment with letting the domU map it at 
other locations in its virtual address space, but I suppose that for 
performance it is mapped as a 4MB ''super'' page, and as such
needs
special treatment, is this correct?

Thanks,
Jacob

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

On 31 Mar 2005, at 04:25, Jacob Gorm Hansen wrote:
> The machine_to_phys_mapping table is mapped permanently at 0xFC000000 
> (on x86-32). I would like to experiment with letting the domU map it 
> at other locations in its virtual address space, but I suppose that 
> for performance it is mapped as a 4MB ''super'' page, and
as such needs
> special treatment, is this correct?
It doesn''t *have* to be mapped as a superpage -- control tools
don''t
when doing suspend/resume, for example. Fixing the permission checking 
so that other than domain0 can remap the m2p table shouldn''t be very 
hard, but I''m not sure what the cleanest method would be.

  -- Keir


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

Keir Fraser wrote:
> 
> On 31 Mar 2005, at 04:25, Jacob Gorm Hansen wrote:
> 
>> The machine_to_phys_mapping table is mapped permanently at 0xFC000000 
>> (on x86-32). I would like to experiment with letting the domU map it 
>> at other locations in its virtual address space, but I suppose that 
>> for performance it is mapped as a 4MB ''super'' page,
and as such needs
>> special treatment, is this correct?
> 
> 
> It doesn''t *have* to be mapped as a superpage -- control tools
don''t
> when doing suspend/resume, for example. Fixing the permission checking 
> so that other than domain0 can remap the m2p table shouldn''t be
very
> hard, but I''m not sure what the cleanest method would be.
actually I would just like for domUs to be able to map it in different 
locations, in order to get a little more flexible memory layout.

I will probably just try and hack something up for my immediate needs.

Jacob


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

> > It doesn''t *have* to be mapped as a superpage -- control 
> tools don''t 
> > when doing suspend/resume, for example. Fixing the 
> permission checking 
> > so that other than domain0 can remap the m2p table 
> shouldn''t be very 
> > hard, but I''m not sure what the cleanest method would be.
> 
> actually I would just like for domUs to be able to map it in 
> different locations, in order to get a little more flexible 
> memory layout.
> 
> I will probably just try and hack something up for my immediate needs.
I''d like to see this as part of a wider campaign to make the virtual
memory layout more flexible ahead of PAE. I think we should make the
hypervisor ''hole'' variable size. This is perhaps best done by
moving
fixmap from the top of memory to the top of the bottom. If we do this I
don''t think we''ll need to turn any of the current constants
into
variables.

As regards where the m2p table, that will need to be variable sized too.
It woul be interesting to run some lmbench numbers just to check that
nothing bad happens if we do away with the 4MB mapping.

Ian

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