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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.08.15 at 15:18, <julien.grall@xxxxxxxxxx> wrote:
> On 05/08/15 13:46, Andrew Cooper wrote:
>> On 05/08/15 13:36, Julien Grall wrote:
>>> 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.

Interesting. Does Linux on ARM not require any atomic page table
entry updates? I ask because I can't see how you would emulate
such when you need to deal with 16 of them at a time.

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

Waste of memory? You're only mapping an existing chunk of memory.
DYM waste of address space?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel