[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 0/6] Runtime pagesize computation
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH v2 0/6] Runtime pagesize computation |
Date: |
Wed, 22 Jun 2016 12:43:17 +0100 |
User-agent: |
Mutt/1.6.1 (2016-04-27) |
* Peter Maydell (address@hidden) 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 / address@hidden / Manchester, UK