On 10/11/2016 03:18 PM, Peter Maydell wrote:
On 11 October 2016 at 12:20, Richard Henderson <r...@twiddle.net> 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~
