Re: [Qemu-devel] [PATCH 3/3] pseries: Correctly create ibm, segment-page-sizes property

[Alexander Graf]

On 30.09.2011, at 09:50, David Gibson wrote:

> Current versions of the PowerPC architecture require and fully define
> 4kB and 16MB page sizes.  Other pagesizes (e.g. 64kB, 1MB) are
> permitted and are often supported, but the exact encodings used to set
> the up can vary from chip to chip.
> 
> The supported pagesizes and required encodings are advertised to the
> OS via the ibm,segment-page-sizes property in the device tree.
> Currently we do not put this property in our device tree, so guests
> are restricted to the architected 4kB and 16MB pagesizes.
> 
> The base sizes are all that we implement in tcg, however with KVM the
> guest can use anything supported by the host as long as the guest's
> base memory is backed by pages at least as large.  Furthermore, in
> order to use any extended page sizes, the guest needs to know the
> correct encodings for the host.
> 
> This patch, therefore, reads the host's pagesize information, filters
> it based on the pagesize backing RAM, and passes it into the guest.
> 
> Signed-off-by: Nishanth Aravamudan <address@hidden>
> Signed-off-by: David Gibson <address@hidden>
> ---
> hw/spapr.c           |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++
> target-ppc/kvm.c     |   43 +++++++++++++++++
> target-ppc/kvm_ppc.h |    6 ++
> 3 files changed, 176 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/spapr.c b/hw/spapr.c
> index 8089d83..72b6c6a 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -24,6 +24,8 @@
>  * THE SOFTWARE.
>  *
>  */
> +#include <sys/vfs.h>
> +
> #include "sysemu.h"
> #include "hw.h"
> #include "elf.h"
> @@ -88,6 +90,122 @@ qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t 
> *irq_num)
>     return qirq;
> }
> 
> +#define HUGETLBFS_MAGIC       0x958458f6
> +
> +static long getrampagesize(void)
> +{
> +    struct statfs fs;
> +    int ret;
> +
> +    if (!mem_path) {
> +        /* guest RAM is backed by normal anonymous pages */
> +        return getpagesize();
> +    }
> +
> +    do {
> +        ret = statfs(mem_path, &fs);
> +    } while (ret != 0 && errno == EINTR);
> +
> +    if (ret != 0) {
> +        fprintf(stderr, "Couldn't statfs() memory path: %s\n",
> +                strerror(errno));
> +        exit(1);
> +    }
> +
> +    if (fs.f_type != HUGETLBFS_MAGIC) {
> +        /* Explicit mempath, but it's ordinary pages */
> +        return getpagesize();
> +    }
> +
> +    /* It's hugepage, return the huge page size */
> +    return fs.f_bsize;
> +}

Would this function compile and work on win32 hosts? If not, it should probably 
go to kvm.c.

> +
> +static size_t create_page_sizes_prop(uint32_t *prop, size_t maxsize)
> +{
> +    int cells;
> +    target_ulong ram_page_size = getrampagesize();
> +    int i, j;
> +
> +    if (!kvm_enabled()) {
> +        /* For the supported CPUs in emulation, we support just 4k and
> +         * 16MB pages, with the usual encodings.  This is the default
> +         * set the guest will assume if we don't specify anything */
> +        return 0;
> +    }
> +
> +    cells = kvmppc_read_segment_page_sizes(prop, maxsize / sizeof(uint32_t));

Shouldn't we rather be asking the kvm kernel module to tell us its supported 
segment sizes? Just because the host doesn't support 256MB page size doesn't 
mean we can't expose it to the guest, right? Depending on the KVM mode of 
course.

For HV we would pass through the hardware ones. For PR we could pretty much 
support anything since we're shadowing the htab. But there it'd be a win too, 
since we would get less page table entries and could potentially also back 
things with huge pages.

Also, this depends heavily on the guest CPU architecture. For 970, we can't 
support anything but 4k and 16MB (and even that one is crap). For p7, things 
are a lot more flexible. But we need to make sure that what we tell the guest 
is actually possible to do on the particular CPU we're emulating / virtualizing.


Alex