From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bu0Xc-0001EW-Ua for qemu-devel@nongnu.org; Tue, 11 Oct 2016 13:08:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bu0Xa-00045w-ML for qemu-devel@nongnu.org; Tue, 11 Oct 2016 13:08:35 -0400 From: Peter Maydell Date: Tue, 11 Oct 2016 18:08:12 +0100 Message-Id: <1476205699-28857-1-git-send-email-peter.maydell@linaro.org> Subject: [Qemu-devel] [PATCH v3 0/7] Runtime pagesize computation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-arm@nongnu.org, qemu-devel@nongnu.org Cc: patches@linaro.org, paolo@archaic.org.uk, Vijaya Kumar K , "Dr . David Alan Gilbert" , Laurent Desnogues , Richard Henderson (I posted version 2 way back in June...) The basic idea here is that: * the target CPU implementation has to opt into variable page size by defining TARGET_PAGE_BITS_VARY, and then calling set_preferred_target_page_bits() in its realize function with whatever the CPU as instantiated actually requires * the machine also has to opt in, by specifying a new MachineClass field which states the value they guarantee will be no greater than the preferred page size for any CPU they create * we finalize the decision about page size in cpu_exec_init_all() (and then later attempts to create CPUs which can't cope with that decision are failed) 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. Note that setting minimum_page-bits for a machine is a migration compatibility break (the RAM migration format assumes both sides have the same idea of a page size). In v3 I have included a patch which adds the target-page-bits to the migration stream so that you get a reasonably nice error message if you try to migrate between source and destination which disagree about the page size. This could in theory be extended to the user-mode binaries, but for the moment I have just required them to define a fixed TARGET_PAGE_BITS. Patches 1-3 have been reviewed, so 4-7 are the interesting ones. REQUEST FOR TESTING/PERFORMANCE BENCHMARKING: I have only very lightly tested these and haven't attempted to measure performance at all. Further testing and benchmarking reports are therefore welcome. In particular I would like to know how much of an effect on TCG performance the assert() in the definition of TARGET_PAGE_BITS has, so comparisons of all three configs: * before this patchset (ie TARGET_PAGE_BITS compile time const) * with this patchset (with assert in TARGET_PAGE_BITS) * this patchset, but with the assert commented out Changes v2->v3: * rebased * added new patch to migrate the page size if it's not the default * virt-2.7 and earlier machines stick with the old default page size to avoid a compat break * in patch 3, v_l1_size is pulled into a local when we're using it as a loop upper bound thanks -- PMM Peter Maydell (4): cpu: Support a target CPU having a variable page size migration/savevm.c: migrate non-default page size target-arm: Make page size a runtime setting hw/arm/virt: Set minimum_page_bits to 12 Vijaya Kumar K (3): migration: Remove static allocation of xzblre cache buffer exec.c: Remove static allocation of sub_section of sub_page translate-all.c: Compute L1 page table properties at runtime exec.c | 47 ++++++++++++++++++++++++++++++--- hw/arm/virt.c | 4 +++ include/exec/cpu-all.h | 9 +++++++ include/hw/boards.h | 7 +++++ include/qemu-common.h | 12 +++++++++ migration/ram.c | 4 ++- migration/savevm.c | 49 ++++++++++++++++++++++++++++++++++ target-arm/cpu.c | 24 +++++++++++++++++ target-arm/cpu.h | 9 ++++--- translate-all.c | 71 ++++++++++++++++++++++++++++++++------------------ vl.c | 10 +++++++ 11 files changed, 213 insertions(+), 33 deletions(-) -- 2.7.4