[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 49/57] Round up RAMBlock sizes to host page sizes
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PULL 49/57] Round up RAMBlock sizes to host page sizes |
Date: |
Wed, 6 Jan 2016 22:27:46 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
On 30/12/2015 01:26, Peter Crosthwaite wrote:
> On Tue, Nov 10, 2015 at 6:25 AM, Juan Quintela <address@hidden> wrote:
>> From: "Dr. David Alan Gilbert" <address@hidden>
>>
>> RAMBlocks that are not a multiple of host pages in length
>> cause problems for postcopy (I've seen an ACPI table on aarch64
>> be 5k in length - i.e. 5x target-page), so round RAMBlock sizes
>> up to a host-page.
>>
>> This potentially breaks migration compatibility due to changes
>> in RAMBlock sizes; however:
>> 1) x86 and s390 I think always have host=target page size
>> 2) When I've tried on Power the block sizes already seem aligned.
>> 3) I don't think there's anything else that maintains per-version
>> machine-types for compatibility.
>>
>
> Is there any reason this shouldn't be converted to
> REAL_HOST_PAGE_ALIGN given these restrictions?
>
> I'm thinking about multi-arch, where HOST_PAGE_ALIGN is inaccessible
> from exec.c as it is target-arch specific. My previous workaround was
> to define the target page size for multi-arch so that TARGET_PAGE_SIZE
> was usable but not sure that should go viral to these other defs.
host_page_size and host_page_mask are really just MAX(host_page_size,
TARGET_PAGE_SIZE) and MIN(qemu_host_page_mask, TARGET_PAGE_MASK). If
you convert them to macros this way, the hack you use for multi-arch
TARGET_PAGE_SIZE will work transparently for HOST_PAGE_{SIZE,MASK}.
Paolo
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [PULL 49/57] Round up RAMBlock sizes to host page sizes,
Paolo Bonzini <=