kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Alexander Graf <graf@amazon.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	Marc Zyngier <marc.zyngier@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>
Subject: Re: [PATCH kvm-unit-tests v2] arm: Add PL031 test
Date: Thu, 25 Jul 2019 14:33:44 +0200	[thread overview]
Message-ID: <20190725123344.4lmeopzyl4jdnsp7@kamzik.brq.redhat.com> (raw)
In-Reply-To: <02a38777-3ec0-0354-8d49-d8ce337e5660@amazon.com>

On Thu, Jul 25, 2019 at 02:12:19PM +0200, Alexander Graf wrote:
> 
> 
> On 15.07.19 18:42, Andrew Jones wrote:
> > On Fri, Jul 12, 2019 at 11:19:38AM +0200, Alexander Graf wrote:
> > > This patch adds a unit test for the PL031 RTC that is used in the virt machine.
> > > It just pokes basic functionality. I've mostly written it to familiarize myself
> > > with the device, but I suppose having the test around does not hurt, as it also
> > > exercises the GIC SPI interrupt path.
> > > 
> > > Signed-off-by: Alexander Graf <graf@amazon.com>
> > > 
> > > ---
> > > 
> > > v1 -> v2:
> > > 
> > >    - Use FDT to find base, irq and existence
> > >    - Put isb after timer read
> > >    - Use dist_base for gicv3
> > > ---
> > >   arm/Makefile.common |   1 +
> > >   arm/pl031.c         | 265 ++++++++++++++++++++++++++++++++++++++++++++
> > >   lib/arm/asm/gic.h   |   1 +
> > >   3 files changed, 267 insertions(+)
> > >   create mode 100644 arm/pl031.c
> > > 
> > > diff --git a/arm/Makefile.common b/arm/Makefile.common
> > > index f0c4b5d..b8988f2 100644
> > > --- a/arm/Makefile.common
> > > +++ b/arm/Makefile.common
> > > @@ -11,6 +11,7 @@ tests-common += $(TEST_DIR)/pmu.flat
> > >   tests-common += $(TEST_DIR)/gic.flat
> > >   tests-common += $(TEST_DIR)/psci.flat
> > >   tests-common += $(TEST_DIR)/sieve.flat
> > > +tests-common += $(TEST_DIR)/pl031.flat
> > 
> > Makefile.common is for both arm32 and arm64, but this code is only
> > compilable on arm64. As there's no reason for it to be arm64 only,
> > then ideally we'd modify the code to allow compiling and running
> > on both, but otherwise we need to move this to Makefile.arm64.
> 
> D'oh. Sorry, I completely missed that bit. Of course we want to test on
> 32bit ARM as well! I'll fix it up :).
> 
> 
> [...]
> 
> > > +static int rtc_fdt_init(void)
> > > +{
> > > +	const struct fdt_property *prop;
> > > +	const void *fdt = dt_fdt();
> > > +	int node, len;
> > > +	u32 *data;
> > > +
> > > +	node = fdt_node_offset_by_compatible(fdt, -1, "arm,pl031");
> > > +	if (node < 0)
> > > +		return -1;
> > > +
> > > +	prop = fdt_get_property(fdt, node, "interrupts", &len);
> > > +	assert(prop && len == (3 * sizeof(u32)));
> > > +	data = (u32 *)prop->data;
> > > +	assert(data[0] == 0); /* SPI */
> > > +	pl031_irq = SPI(fdt32_to_cpu(data[1]));
> > 
> > Nit: Ideally we'd add some more devicetree API to get interrupts. With
> > that, and the existing devicetree API, we could remove all low-level fdt
> > related code in this function.
> 
> Well, we probably want some really high level fdt API that can traverse reg
> properly to map bus regs into physical addresses. As long as we don't have
> all that magic,

We do have much of that magic already. Skim through lib/devicetree.h to
see what's available.

> I see little point in inventing anything that looks more
> sophisticated but doesn't actually take the difficult problems into account
> :).

Well, for this case, the "interrupts" decoding isn't difficult and could
be shared among other devices if we added it to devicetree.c. And the
reg decoding below to get the base address is already supported by the
devicetree API.

All that said, it's just a nit that I won't insist on though, because it's
hard enough to get unit test contributors without asking that they also
contribute to the framework.

> 
> > 
> > > +
> > > +	prop = fdt_get_property(fdt, node, "reg", &len);
> > > +	assert(prop && len == (2 * sizeof(u64)));
> > > +	data = (u32 *)prop->data;
> > > +	pl031 = (void*)((ulong)fdt32_to_cpu(data[0]) << 32 | fdt32_to_cpu(data[1]));
> > 
> > This works because we currently ID map all the physical memory. I usually
> > try to remember to use an ioremap in these cases anyway though.
> 
> Great idea - it allows me to get rid of a bit of casting too.
>

Thanks,
drew

  reply	other threads:[~2019-07-25 12:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12  9:19 [PATCH kvm-unit-tests v2] arm: Add PL031 test Alexander Graf
2019-07-15 16:42 ` Andrew Jones
2019-07-25 12:12   ` Alexander Graf
2019-07-25 12:33     ` Andrew Jones [this message]
2019-07-25 12:58       ` Alexander Graf

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=20190725123344.4lmeopzyl4jdnsp7@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=graf@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=marc.zyngier@arm.com \
    --cc=pbonzini@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 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).