Re: [Qemu-devel] [PATCH v2 0/6] Runtime pagesize computation

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> This set of patches is a development based on the ones from Vijaya:
> the general idea is similar but I have tried to improve the interface
> for defining the page size a bit.  I've also tweaked patches 2 and 3
> to address code review comments.
> 
> 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). Mismatches will probably
> result in an unhelpfully obscure migration failure. (Possibly we
> could have the migration send the page size if it was different
> from TARGET_PAGE_BITS_MIN so we at least got a nice error?)

Yes, that would be a good idea;  how about adding it as a subsection
in the vmstate_configuration (migration/savevm.c); if you only
send it in the case where it's not the existing size then it shouldn't
break any old formats.  That configuration block gets loaded
very early.

Dave

> 
> 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.
> 
> NB: I have only very lightly tested these and haven't attempted
> to measure performance at all. There is an assert() in the
> definition of TARGET_PAGE_BITS which is good for making sure
> it isn't used before it's valid but not so good for speed.
> 
> thanks
> -- PMM
> 
> 
> Peter Maydell (3):
>   cpu: Support a target CPU having a variable 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          |  2 ++
>  include/exec/cpu-all.h |  8 ++++++
>  include/hw/boards.h    |  7 ++++++
>  include/qemu-common.h  | 13 ++++++++++
>  migration/ram.c        |  4 ++-
>  target-arm/cpu.c       | 24 ++++++++++++++++++
>  target-arm/cpu.h       |  9 ++++---
>  translate-all.c        | 67 +++++++++++++++++++++++++++++++++-----------------
>  vl.c                   | 10 ++++++++
>  10 files changed, 160 insertions(+), 31 deletions(-)
> 
> -- 
> 1.9.1
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK