Re: [RFC 1/2] xen/mm: Clarify the granularity for each Frame Number

[Julien Grall <julien.grall@citrix.com>]

Hi,

On 05/08/15 13:46, Andrew Cooper wrote:
> On 05/08/15 13:36, Julien Grall wrote:
>> On 05/08/15 12:40, Andrew Cooper wrote:
>>> I think a section about granularity is worthwhile, but probably a
>>> separate paragraph.  I think it is also worth keeping Xen's idea of
>>> memory all at 4K, and in cases where 64K is in use, require appropriate
>>> alignment in the parameter.
>> Which would confuse the reader because PFN which, based on the
>> description, is the OS Frame Number. This frame will always be in the
>> granularity of the OS.
> 
> "A linear idea of a guest physical address space." says nothing about
> the OS.  It is purely a Xen concept, as described here.

Right. Thank you for your explanation IRL.

I will have to find another place to clear specify the granularity of
the hypercalls.

>>
>> So we need to introduce the concept of in each definition. This patch
>> makes clear that MFN and GFN is always 4KB and PFN may vary.
> 
> Is (or rather will) a 4K dom0 able to make 4K mappings of a 64K domU? 
> How is a 64K dom0 expected to make mappings of a 4K domU?

The Xen interface will stay 4K even with 64K guest. We have to support
64K guest/dom0 on the current Xen because some distro may do the choice
to only ship 64K.

In my current implementation of Linux 64K support (see [1]), there is no
changes in Xen (hypervisor and tools). Linux is breaking the 64K page in
4K chunk.

When the backend is 64K, it will map the foreign 4K at the top of a 64K
page. It's a waste of memory, but it's easier to implement and it's
still and improvement compare to have Linux crashing at boot.

Note that there is lots of room of improvement but I'd like to get a
series as soon as possible. That doesn't mean we should have a hack,
just something sensible and working.

> The primary use of "pfn" in Xen is logdirty tracking (which ARM doesn't
> have yet), but will have to be set at the minimum granularity of the
> toolstack domain, domU and the logdirty ABI which currently is assumed
> to be 4K pages because of its x86 heritage.

Which will be fine for ARM given that ARM32 only supports 4K.

Regards,

[1] https://lkml.org/lkml/2015/7/9/611

-- 
Julien Grall