Is machine_to_phys_mapping a 4MB 'superpage'?

Is machine_to_phys_mapping a 4MB 'superpage'?

[Jacob Gorm Hansen]

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

Re: Is machine_to_phys_mapping a 4MB 'superpage'?

[Keir Fraser]

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

Re: Is machine_to_phys_mapping a 4MB 'superpage'?

[Jacob Gorm Hansen]

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

RE: Is machine_to_phys_mapping a 4MB 'superpage'?

[Ian Pratt]

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