qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v3 0/7] Runtime pagesize computation


From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH v3 0/7] Runtime pagesize computation
Date: Tue, 11 Oct 2016 18:38:14 +0100

Oops, I messed up Paolo's email address sending this.
Sorry about that...

thanks
-- PMM

On 11 October 2016 at 18:08, Peter Maydell <address@hidden> wrote:
> (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(-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]