All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, frankja@linux.ibm.com,
	david@redhat.com, thuth@redhat.com, cohuck@redhat.com,
	lvivier@redhat.com
Subject: Re: [kvm-unit-tests PATCH v2 3/7] lib/asm: Add definitions of memory areas
Date: Sat, 3 Oct 2020 11:23:27 +0200	[thread overview]
Message-ID: <20201003092327.5xl7nzx27o35jqwf@kamzik.brq.redhat.com> (raw)
In-Reply-To: <20201002154420.292134-4-imbrenda@linux.ibm.com>

On Fri, Oct 02, 2020 at 05:44:16PM +0200, Claudio Imbrenda wrote:
> Add definitions and boundaries of memory areas for some architectures.
> This is needed by the next patch.
> 
> Most architectures only get one generic memory area, wherease x86 and
> s390x get some more attention:
> 
> x86 gets
> * lowest area (24-bit addresses)
> * low area (32-bit addresses)
> * the rest
> 
> s390x gets
> * low area (31-bit addresses)
> * the rest
> 
> Notice that the number indicates the order in which the areas are
> scanned when more than one area is indicated. The default order tries
> to get allocations from higher address ranges before trying lower ones.
> This tries to keep the precious lower addresses as free as possible.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> ---
>  lib/asm-generic/memory_areas.h | 11 +++++++++++
>  lib/arm/asm/memory_areas.h     | 11 +++++++++++
>  lib/arm64/asm/memory_areas.h   | 11 +++++++++++
>  lib/powerpc/asm/memory_areas.h | 11 +++++++++++
>  lib/ppc64/asm/memory_areas.h   | 11 +++++++++++
>  lib/s390x/asm/memory_areas.h   | 17 +++++++++++++++++
>  lib/x86/asm/memory_areas.h     | 22 ++++++++++++++++++++++
>  7 files changed, 94 insertions(+)
>  create mode 100644 lib/asm-generic/memory_areas.h
>  create mode 100644 lib/arm/asm/memory_areas.h
>  create mode 100644 lib/arm64/asm/memory_areas.h
>  create mode 100644 lib/powerpc/asm/memory_areas.h
>  create mode 100644 lib/ppc64/asm/memory_areas.h
>  create mode 100644 lib/s390x/asm/memory_areas.h
>  create mode 100644 lib/x86/asm/memory_areas.h
> 
> diff --git a/lib/asm-generic/memory_areas.h b/lib/asm-generic/memory_areas.h
> new file mode 100644
> index 0000000..927baa7
> --- /dev/null
> +++ b/lib/asm-generic/memory_areas.h
> @@ -0,0 +1,11 @@
> +#ifndef MEMORY_AREAS_H

_ASM_GENERIC_MEMORY_AREAS_H_

> +#define MEMORY_AREAS_H
> +
> +#define AREA_NORMAL_PFN 0
> +#define AREA_NORMAL_NUMBER 0
> +#define AREA_NORMAL 1
> +
> +#define AREA_ANY -1
> +#define AREA_ANY_NUMBER 0xff

Do we really need both a "type number", like AREA_NORMAL, and a
"number number" (AREA_NORMAL_NUMBER)? Why not just search in the order
of the type numbers? Or in the reverse order, if that's better? Also,
would an enum be more appropriate for the type numbers?

> +
> +#endif
> diff --git a/lib/arm/asm/memory_areas.h b/lib/arm/asm/memory_areas.h
> new file mode 100644
> index 0000000..927baa7
> --- /dev/null
> +++ b/lib/arm/asm/memory_areas.h
> @@ -0,0 +1,11 @@
> +#ifndef MEMORY_AREAS_H

_ASMARM_MEMORY_AREAS_H_

We certainly don't want the same define as the generic file, as it's
possible an arch will want to simply extend the generic code, e.g.

 #ifndef _ASMARM_MEMORY_AREAS_H_
 #define _ASMARM_MEMORY_AREAS_H_
 #include #include <asm-generic/memory_areas.h>

 /* ARM memory area stuff here */

 #endif

This comment applies to the rest of memory_areas.h files. Look at
other lib/$ARCH/asm/*.h files to get the define prefix.

> +#define MEMORY_AREAS_H
> +
> +#define AREA_NORMAL_PFN 0
> +#define AREA_NORMAL_NUMBER 0
> +#define AREA_NORMAL 1
> +
> +#define AREA_ANY -1
> +#define AREA_ANY_NUMBER 0xff
> +
> +#endif
[...]
> diff --git a/lib/s390x/asm/memory_areas.h b/lib/s390x/asm/memory_areas.h
> new file mode 100644
> index 0000000..4856a27
> --- /dev/null
> +++ b/lib/s390x/asm/memory_areas.h
> @@ -0,0 +1,17 @@
> +#ifndef MEMORY_AREAS_H
> +#define MEMORY_AREAS_H
> +
> +#define AREA_NORMAL_PFN BIT(31-12)

BIT(31 - PAGE_SHIFT)

> +#define AREA_NORMAL_NUMBER 0
> +#define AREA_NORMAL 1
> +
> +#define AREA_LOW_PFN 0
> +#define AREA_LOW_NUMBER 1
> +#define AREA_LOW 2
> +
> +#define AREA_ANY -1
> +#define AREA_ANY_NUMBER 0xff
> +
> +#define AREA_DMA31 AREA_LOW

I don't work on s390x, but I'd rather not add too many aliases. I think
a single name with the min and max address bits embedded in it is
probably best. Maybe something like AREA_0_31 and AREA_31_52, or
whatever.

> +
> +#endif
> diff --git a/lib/x86/asm/memory_areas.h b/lib/x86/asm/memory_areas.h
> new file mode 100644
> index 0000000..d704df3
> --- /dev/null
> +++ b/lib/x86/asm/memory_areas.h
> @@ -0,0 +1,22 @@
> +#ifndef MEMORY_AREAS_H
> +#define MEMORY_AREAS_H
> +
> +#define AREA_NORMAL_PFN BIT(32-12)
> +#define AREA_NORMAL_NUMBER 0
> +#define AREA_NORMAL 1
> +
> +#define AREA_LOW_PFN BIT(24-12)
> +#define AREA_LOW_NUMBER 1
> +#define AREA_LOW 2
> +
> +#define AREA_LOWEST_PFN 0
> +#define AREA_LOWEST_NUMBER 2
> +#define AREA_LOWEST 4
> +
> +#define AREA_DMA24 AREA_LOWEST
> +#define AREA_DMA32 (AREA_LOWEST | AREA_LOW)

Aha, now I finally see that there's a type number and a number number
because the type number is a bit, presumably for some flag field that's
coming in a later patch. I'll have to look at the other patches to see
how that's used, but at the moment I feel like there should be another
way to represent memory areas without requiring a handful of defines
and aliases for each one.

Thanks,
drew

> +
> +#define AREA_ANY -1
> +#define AREA_ANY_NUMBER 0xff
> +
> +#endif
> -- 
> 2.26.2
> 


  reply	other threads:[~2020-10-03  9:23 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 15:44 [kvm-unit-tests PATCH v2 0/7] Rewrite the allocators Claudio Imbrenda
2020-10-02 15:44 ` [kvm-unit-tests PATCH v2 1/7] lib/list: Add double linked list management functions Claudio Imbrenda
2020-10-02 18:18   ` Andrew Jones
2020-10-05  6:57     ` Claudio Imbrenda
2020-11-06 11:29   ` Paolo Bonzini
2020-10-02 15:44 ` [kvm-unit-tests PATCH v2 2/7] lib/vmalloc: vmalloc support for handling allocation metadata Claudio Imbrenda
2020-10-03  8:46   ` Andrew Jones
2020-10-05  7:00     ` Claudio Imbrenda
2020-10-02 15:44 ` [kvm-unit-tests PATCH v2 3/7] lib/asm: Add definitions of memory areas Claudio Imbrenda
2020-10-03  9:23   ` Andrew Jones [this message]
2020-10-05  7:10     ` Claudio Imbrenda
2020-11-06 11:34   ` Paolo Bonzini
2020-11-06 12:58     ` Claudio Imbrenda
2020-11-06 13:04       ` Paolo Bonzini
2020-10-02 15:44 ` [kvm-unit-tests PATCH v2 4/7] lib/alloc_page: complete rewrite of the page allocator Claudio Imbrenda
2020-10-05 12:40   ` Andrew Jones
2020-10-05 15:56     ` Claudio Imbrenda
2020-10-05 16:53       ` Andrew Jones
2020-10-05 17:18         ` Claudio Imbrenda
2020-10-05 18:04           ` Andrew Jones
2020-12-08  0:41   ` Nadav Amit
2020-12-08  1:10     ` Nadav Amit
2020-12-08  9:15       ` Claudio Imbrenda
2020-12-08  9:23         ` Nadav Amit
2020-12-08 10:00           ` Claudio Imbrenda
2020-12-08 12:48             ` Nadav Amit
2020-12-08 13:41               ` Claudio Imbrenda
2020-12-08 14:26                 ` Andrew Jones
2020-12-09  8:53                   ` Claudio Imbrenda
2020-12-08  9:11     ` Claudio Imbrenda
2020-12-08  9:16       ` Nadav Amit
2020-10-02 15:44 ` [kvm-unit-tests PATCH v2 5/7] lib/alloc: simplify free and malloc Claudio Imbrenda
2020-10-02 15:44 ` [kvm-unit-tests PATCH v2 6/7] lib/alloc.h: remove align_min from struct alloc_ops Claudio Imbrenda
2020-11-06 11:35   ` Paolo Bonzini
2020-11-06 12:56     ` Claudio Imbrenda
2020-10-02 15:44 ` [kvm-unit-tests PATCH v2 7/7] lib/alloc_page: allow reserving arbitrary memory ranges Claudio Imbrenda
2020-10-05 11:54 ` [kvm-unit-tests PATCH v2 0/7] Rewrite the allocators Pierre Morel
2020-10-05 12:35   ` Claudio Imbrenda
2020-10-05 12:49     ` Andrew Jones
2020-10-05 12:57     ` Pierre Morel
2020-10-05 14:59       ` Claudio Imbrenda
2020-11-06 11:36 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201003092327.5xl7nzx27o35jqwf@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.