[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.