|
From: | Richard Henderson |
Subject: | Re: [Qemu-devel] [PATCH v3 0/7] Runtime pagesize computation |
Date: | Tue, 11 Oct 2016 20:34:53 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
On 10/11/2016 03:18 PM, Peter Maydell wrote:
On 11 October 2016 at 12:20, Richard Henderson <address@hidden> wrote:On 10/11/2016 12:08 PM, Peter Maydell wrote:I would ideally have liked to finalize things much later, but this is in practice hugely difficult because so many things (in particular all the address space/memory system code) assume the target page size is known.Unfortunate. I suppose that 4k is still better than 1k, but I was hoping to get 16k or 64k (or higher) when the OS is configured to use such. I.e. totally dynamically configurable upon write to the appropriate cpu register.I think that would run into problems with migration: the migration stream all works in guest-pages of ram and a mismatch means migration doesn't work.
Perhaps migration should use definitions based off of TARGET_PAGE_BITS_MIN? Dunno how big of a job that would be...
The trouble is that all the data structures work in terms of page sizes (even though we support sub-page allocations those are still done by carving up a page-size chunk). It could probably be done but it looked like a gargantuan task so I decided this was a better compromise.
Fair enough. This is still an improvement for an interesting guest. r~
[Prev in Thread] | Current Thread | [Next in Thread] |