>>> On 12.08.15 at 14:57, wrote:
> On 12/08/15 12:58, Jan Beulich wrote:
> On 12.08.15 at 13:13, wrote:
>>> On 12/08/15 11:33, Jan Beulich wrote:
>>> On 12.08.15 at 11:57, wrote:
> On 12/08/2015 08:16, Jan Beulich wrote:
> On 05.08.15 at 15:18, wrote:
>>> When the backen
On 12/08/15 12:58, Jan Beulich wrote:
On 12.08.15 at 13:13, wrote:
>> On 12/08/15 11:33, Jan Beulich wrote:
>> On 12.08.15 at 11:57, wrote:
On 12/08/2015 08:16, Jan Beulich wrote:
On 05.08.15 at 15:18, wrote:
>> When the backend is 64K, it will map the foreign 4K at th
>>> On 12.08.15 at 13:13, wrote:
> On 12/08/15 11:33, Jan Beulich wrote:
> On 12.08.15 at 11:57, wrote:
>>> On 12/08/2015 08:16, Jan Beulich wrote:
>>> On 05.08.15 at 15:18, wrote:
> When the backend is 64K, it will map the foreign 4K at the top of a 64K
> page. It's a waste of m
On 12/08/15 11:33, Jan Beulich wrote:
On 12.08.15 at 11:57, wrote:
>> On 12/08/2015 08:16, Jan Beulich wrote:
>> On 05.08.15 at 15:18, 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 de
>>> On 12.08.15 at 11:57, wrote:
> On 12/08/2015 08:16, Jan Beulich wrote:
> On 05.08.15 at 15:18, 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
Hi Jan,
On 12/08/2015 08:16, Jan Beulich wrote:
On 05.08.15 at 15:18, 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
>>> On 05.08.15 at 15:18, 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
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
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
>>
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 conf
On Wed, 2015-08-05 at 12:40 +0100, Andrew Cooper wrote:
>
> 64K granularity is also similar to 2M/1G superpages in their handling,
> the difference being that 64K can't be subdivided if necessary?
64K is actually a separate basic "granule" (to use the ARM term), i.e.
alternative to the 4K leaf pa
On 05/08/15 12:28, Julien Grall wrote:
> From: Stefano Stabellini
>
> ARM64 is able to support 64KB and 4KB page granularities. While the guest
> will support both granularities, Xen and hypercall interface will always
> be in 4KB.
>
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Julien Gra
From: Stefano Stabellini
ARM64 is able to support 64KB and 4KB page granularities. While the guest
will support both granularities, Xen and hypercall interface will always
be in 4KB.
Signed-off-by: Stefano Stabellini
Signed-off-by: Julien Grall
---
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan B
13 matches
Mail list logo