From: Thomas Huth <thuth@redhat.com>
To: Nicholas Piggin <npiggin@gmail.com>, kvm@vger.kernel.org
Cc: Laurent Vivier <lvivier@redhat.com>, linuxppc-dev@lists.ozlabs.org
Subject: Re: [kvm-unit-tests v2 06/10] powerpc/sprs: Specify SPRs with data rather than code
Date: Thu, 23 Mar 2023 13:36:18 +0100 [thread overview]
Message-ID: <f03084cc-8ac6-b2cb-b2e8-39bc73843ab7@redhat.com> (raw)
In-Reply-To: <20230320070339.915172-7-npiggin@gmail.com>
On 20/03/2023 08.03, Nicholas Piggin wrote:
> A significant rework that builds an array of 'struct spr', where each
> element describes an SPR. This makes various metadata about the SPR
> like name and access type easier to carry and use.
>
> Hypervisor privileged registers are described despite not being used
> at the moment for completeness, but also the code might one day be
> reused for a hypervisor-privileged test.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>
> This ended up a little over-engineered perhaps, but there are lots of
> SPRs, lots of access types, lots of changes between processor and ISA
> versions, and lots of places they are implemented and used, so lots of
> room for mistakes. There is not a good system in place to easily
> see that userspace, supervisor, etc., switches perform all the right
> SPR context switching so this is a nice test case to have. The sprs test
> quickly caught a few QEMU TCG SPR bugs which really motivated me to
> improve the SPR coverage.
> ---
> powerpc/sprs.c | 589 +++++++++++++++++++++++++++++++++----------------
> 1 file changed, 394 insertions(+), 195 deletions(-)
>
> diff --git a/powerpc/sprs.c b/powerpc/sprs.c
> index db341a9..dd83dac 100644
> --- a/powerpc/sprs.c
> +++ b/powerpc/sprs.c
> @@ -82,231 +82,407 @@ static void mtspr(unsigned spr, uint64_t val)
> : "lr", "ctr", "xer");
> }
>
> -uint64_t before[1024], after[1024];
> +static uint64_t before[1024], after[1024];
>
> -/* Common SPRs for all PowerPC CPUs */
> -static void set_sprs_common(uint64_t val)
> -{
> - // mtspr(9, val); /* CTR */ /* Used by mfspr/mtspr */
> - // mtspr(273, val); /* SPRG1 */ /* Used by our exception handler */
> - mtspr(274, val); /* SPRG2 */
> - mtspr(275, val); /* SPRG3 */
> -}
> +#define SPR_PR_READ 0x0001
> +#define SPR_PR_WRITE 0x0002
> +#define SPR_OS_READ 0x0010
> +#define SPR_OS_WRITE 0x0020
> +#define SPR_HV_READ 0x0100
> +#define SPR_HV_WRITE 0x0200
> +
> +#define RW 0x333
> +#define RO 0x111
> +#define WO 0x222
> +#define OS_RW 0x330
> +#define OS_RO 0x110
> +#define OS_WO 0x220
> +#define HV_RW 0x300
> +#define HV_RO 0x100
> +#define HV_WO 0x200
> +
> +#define SPR_ASYNC 0x1000 /* May be updated asynchronously */
> +#define SPR_INT 0x2000 /* May be updated by synchronous interrupt */
> +#define SPR_HARNESS 0x4000 /* Test harness uses the register */
> +
> +struct spr {
> + const char *name;
> + uint8_t width;
> + uint16_t access;
> + uint16_t type;
> +};
> +
> +/* SPRs common denominator back to PowerPC Operating Environment Architecture */
> +static const struct spr sprs_common[1024] = {
> + [1] = {"XER", 64, RW, SPR_HARNESS, }, /* Compiler */
> + [8] = {"LR", 64, RW, SPR_HARNESS, }, /* Compiler, mfspr/mtspr */
> + [9] = {"CTR", 64, RW, SPR_HARNESS, }, /* Compiler, mfspr/mtspr */
> + [18] = {"DSISR", 32, OS_RW, SPR_INT, },
> + [19] = {"DAR", 64, OS_RW, SPR_INT, },
> + [26] = {"SRR0", 64, OS_RW, SPR_INT, },
> + [27] = {"SRR1", 64, OS_RW, SPR_INT, },
> +[268] = {"TB", 64, RO , SPR_ASYNC, },
> +[269] = {"TBU", 32, RO, SPR_ASYNC, },
> +[272] = {"SPRG0", 64, OS_RW, SPR_HARNESS, }, /* Int stack */
> +[273] = {"SPRG1", 64, OS_RW, SPR_HARNESS, }, /* Scratch */
> +[274] = {"SPRG2", 64, OS_RW, },
> +[275] = {"SPRG3", 64, OS_RW, },
> +[287] = {"PVR", 32, OS_RO, },
> +};
Using a size of 1024 for each of these arrays looks weird. Why don't you add
a "nr" field to struct spr and specify the register number via that field
instead of using the index into the array as register number?
Thomas
next prev parent reply other threads:[~2023-03-23 12:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 7:03 [kvm-unit-tests v2 00/10] powerpc: updates, P10, PNV support Nicholas Piggin
2023-03-20 7:03 ` [kvm-unit-tests v2 01/10] MAINTAINERS: Update powerpc list Nicholas Piggin
2023-03-23 11:23 ` Thomas Huth
2023-03-20 7:03 ` [kvm-unit-tests v2 02/10] powerpc: add local variant of SPR test Nicholas Piggin
2023-03-23 11:26 ` Thomas Huth
2023-03-27 5:37 ` Nicholas Piggin
2023-03-20 7:03 ` [kvm-unit-tests v2 03/10] powerpc: abstract H_CEDE calls into a sleep functions Nicholas Piggin
2023-03-23 12:12 ` Thomas Huth
2023-03-27 5:39 ` Nicholas Piggin
2023-03-20 7:03 ` [kvm-unit-tests v2 04/10] powerpc: Add ISA v3.1 (POWER10) support to SPR test Nicholas Piggin
2023-03-23 12:01 ` Thomas Huth
2023-03-20 7:03 ` [kvm-unit-tests v2 05/10] powerpc: Indirect SPR accessor functions Nicholas Piggin
2023-03-20 7:03 ` [kvm-unit-tests v2 06/10] powerpc/sprs: Specify SPRs with data rather than code Nicholas Piggin
2023-03-23 12:36 ` Thomas Huth [this message]
2023-03-27 11:59 ` Nicholas Piggin
2023-03-20 7:03 ` [kvm-unit-tests v2 07/10] powerpc/spapr_vpa: Add basic VPA tests Nicholas Piggin
2023-03-23 14:07 ` Thomas Huth
2023-03-27 6:27 ` Nicholas Piggin
2023-03-20 7:03 ` [kvm-unit-tests v2 08/10] powerpc: Discover runtime load address dynamically Nicholas Piggin
2023-03-20 7:03 ` [kvm-unit-tests v2 09/10] powerpc: Support powernv machine with QEMU TCG Nicholas Piggin
2023-03-20 9:47 ` Cédric Le Goater
2023-03-21 0:38 ` Nicholas Piggin
2023-03-23 14:14 ` Thomas Huth
2023-03-20 7:03 ` [kvm-unit-tests v2 10/10] powerpc/sprs: Test hypervisor registers on powernv machine Nicholas Piggin
2023-03-23 14:16 ` Thomas Huth
2023-03-21 6:14 ` [kvm-unit-tests v2 00/10] powerpc: updates, P10, PNV support Nicholas Piggin
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=f03084cc-8ac6-b2cb-b2e8-39bc73843ab7@redhat.com \
--to=thuth@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lvivier@redhat.com \
--cc=npiggin@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).