qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Akihiko Odaki" <akihiko.odaki@daynix.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"John Snow" <jsnow@redhat.com>,
	"BALATON Zoltan" <balaton@eik.bme.hu>,
	"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Harsh Prateek Bora" <harshpb@linux.ibm.com>,
	"Alexey Kardashevskiy" <aik@ozlabs.ru>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Peter Xu" <peterx@redhat.com>, "Fabiano Rosas" <farosas@suse.de>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	qemu-ppc@nongnu.org
Subject: Re: [PATCH v2 06/15] ppc/vof: Fix unaligned FDT property access
Date: Fri, 5 Jul 2024 11:41:13 +1000	[thread overview]
Message-ID: <ZodPOTAcLo1XF4MB@zatzit> (raw)
In-Reply-To: <D2H7KBZF8OA4.3EKIA8NHHJ3MJ@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4587 bytes --]

On Fri, Jul 05, 2024 at 11:18:47AM +1000, Nicholas Piggin wrote:
> On Thu Jul 4, 2024 at 10:15 PM AEST, Peter Maydell wrote:
> > On Sat, 29 Jun 2024 at 04:17, David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > On Fri, Jun 28, 2024 at 04:20:02PM +0100, Peter Maydell wrote:
> > > > On Thu, 27 Jun 2024 at 14:39, Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
> > > > >
> > > > > FDT properties are aligned by 4 bytes, not 8 bytes.
> > > > >
> > > > > Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> > > > > ---
> > > > >  hw/ppc/vof.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/hw/ppc/vof.c b/hw/ppc/vof.c
> > > > > index e3b430a81f4f..b5b6514d79fc 100644
> > > > > --- a/hw/ppc/vof.c
> > > > > +++ b/hw/ppc/vof.c
> > > > > @@ -646,7 +646,7 @@ static void vof_dt_memory_available(void *fdt, GArray *claimed, uint64_t base)
> > > > >      mem0_reg = fdt_getprop(fdt, offset, "reg", &proplen);
> > > > >      g_assert(mem0_reg && proplen == sizeof(uint32_t) * (ac + sc));
> > > > >      if (sc == 2) {
> > > > > -        mem0_end = be64_to_cpu(*(uint64_t *)(mem0_reg + sizeof(uint32_t) * ac));
> > > > > +        mem0_end = ldq_be_p(mem0_reg + sizeof(uint32_t) * ac);
> > > > >      } else {
> > > > >          mem0_end = be32_to_cpu(*(uint32_t *)(mem0_reg + sizeof(uint32_t) * ac));
> > > > >      }
> > > >
> > > > I did wonder if there was a better way to do what this is doing,
> > > > but neither we (in system/device_tree.c) nor libfdt seem to
> > > > provide one.
> > >
> > > libfdt does provide unaligned access helpers (fdt32_ld() etc.), but
> > > not an automatic aligned-or-unaligned helper.   Maybe we should add that?
> >
> > fdt32_ld() and friends only do the "load from this bit of memory"
> > part, which we already have QEMU utility functions for (and which
> > are this patch uses).
> >
> > This particular bit of code is dealing with an fdt property ("memory")
> > that is an array of (address, size) tuples where address and size
> > can independently be either 32 or 64 bits, and it wants the
> > size value of tuple 0. So the missing functionality is something at
> > a higher level than fdt32_ld() which would let you say "give me
> > tuple N field X" with some way to specify the tuple layout. (Which
> > is an awkward kind of API to write in C.)
> >
> > Slightly less general, but for this case we could perhaps have
> > something like the getprop equivalent of qemu_fdt_setprop_sized_cells():
> >
> >   uint64_t value_array[2];
> >   qemu_fdt_getprop_sized_cells(fdt, nodename, "memory", &value_array,
> >                                ac, sc);
> >   /*
> >    * fills in value_array[0] with address, value_array[1] with size,
> >    * probably barfs if the varargs-list of cell-sizes doesn't
> >    * cover the whole property, similar to the current assert on
> >    * proplen.
> >    */
> >   mem0_end = value_array[0];
> 
> Since 4/8 byte cells are most common and size is probably
> normally known, what about something simpler to start with?

Hrm, I don't think this helps much.  As Peter points out the actual
load isn't really the issue, it's locating the right spot for it.

> 
> Thanks,
> Nick
> 
> ---
> diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
> index 0677fea..c4b6355 100644
> --- a/libfdt/libfdt.h
> +++ b/libfdt/libfdt.h
> @@ -148,6 +148,15 @@ static inline uint32_t fdt32_ld(const fdt32_t *p)
>  		| bp[3];
>  }
>  
> +/*
> + * Load the value from a 32-bit cell of a property. Cells are 32-bit aligned
> + * so can use a single load.
> + */
> +static inline uint32_t fdt32_ld_prop(const fdt32_t *p)
> +{
> +	return fdt32_to_cpu(*p);
> +}
> +
>  static inline void fdt32_st(void *property, uint32_t value)
>  {
>  	uint8_t *bp = (uint8_t *)property;
> @@ -172,6 +181,18 @@ static inline uint64_t fdt64_ld(const fdt64_t *p)
>  		| bp[7];
>  }
>  
> +/*
> + * Load the value from a 64-bit cell of a property. Cells are 32-bit aligned
> + * so can use two loads.
> + */
> +static inline uint64_t fdt64_ld_prop(const fdt64_t *p)
> +{
> +	const fdt64_t *_p = p;
> +
> +	return ((uint64_t)fdt32_to_cpu(_p[0]) << 32)
> +		| fdt32_to_cpu(_p[1]);
> +}
> +
>  static inline void fdt64_st(void *property, uint64_t value)
>  {
>  	uint8_t *bp = (uint8_t *)property;
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-07-05  2:08 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 13:37 [PATCH v2 00/15] Fix check-qtest-ppc64 sanitizer errors Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 01/15] cpu: Free cpu_ases Akihiko Odaki
2024-06-28 15:12   ` Peter Maydell
2024-06-27 13:37 ` [PATCH v2 02/15] hw/ide: Convert macio ide_irq into GPIO line Akihiko Odaki
2024-06-28  7:19   ` Mark Cave-Ayland
2024-06-27 13:37 ` [PATCH v2 03/15] hw/ide: Remove internal DMA qemu_irq Akihiko Odaki
2024-06-28  7:23   ` Mark Cave-Ayland
2024-06-27 13:37 ` [PATCH v2 04/15] hw/isa/vt82c686: Define a GPIO line between vt82c686 and i8259 Akihiko Odaki
2024-06-28  7:27   ` Mark Cave-Ayland
2024-06-29  7:38     ` Akihiko Odaki
2024-06-29  8:04       ` Akihiko Odaki
2024-06-29 13:08   ` BALATON Zoltan
2024-07-01 10:32     ` Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 05/15] spapr: Free stdout path Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 06/15] ppc/vof: Fix unaligned FDT property access Akihiko Odaki
2024-06-28 15:20   ` Peter Maydell
2024-06-29  3:16     ` David Gibson
2024-07-04 11:54       ` Nicholas Piggin
2024-07-04 12:15       ` Peter Maydell
2024-07-05  1:18         ` Nicholas Piggin
2024-07-05  1:41           ` David Gibson [this message]
2024-07-05  4:40             ` Nicholas Piggin
2024-07-05  5:12               ` David Gibson
2024-07-05  7:50                 ` Nicholas Piggin
2024-07-06  9:07                   ` Akihiko Odaki
2024-07-06 10:37                 ` Peter Maydell
2024-07-06 23:46                   ` David Gibson
2024-07-08  7:49                     ` Nicholas Piggin
2024-07-08 15:59                       ` Peter Maydell
2024-07-09  7:46                         ` David Gibson
2024-07-09  7:41                       ` David Gibson
2024-07-05  1:33         ` David Gibson
2024-06-27 13:37 ` [PATCH v2 07/15] hw/virtio: Free vqs after vhost_dev_cleanup() Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 08/15] migration: Free removed SaveStateEntry Akihiko Odaki
2024-08-02 12:47   ` (subset) " Fabiano Rosas
2024-06-27 13:37 ` [PATCH v2 09/15] memory: Do not create circular reference with subregion Akihiko Odaki
2024-07-02 17:44   ` Peter Xu
2024-07-06 11:59     ` Akihiko Odaki
2024-07-08  8:06       ` Philippe Mathieu-Daudé
2024-07-08  8:41         ` Akihiko Odaki
2024-07-08 16:40         ` Peter Xu
2024-07-11  8:38           ` Akihiko Odaki
2024-08-22 17:10   ` Peter Maydell
2024-08-22 21:01     ` Peter Xu
2024-08-23  6:17       ` Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 10/15] tests/qtest: Use qtest_add_data_func_full() Akihiko Odaki
2024-07-02  6:14   ` Thomas Huth
2024-06-27 13:37 ` [PATCH v2 11/15] tests/qtest: Free unused QMP response Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 12/15] tests/qtest: Free old machine variable name Akihiko Odaki
2024-06-28 15:21   ` Peter Maydell
2024-06-27 13:37 ` [PATCH v2 13/15] tests/qtest: Delete previous boot file Akihiko Odaki
2024-07-02  7:31   ` Thomas Huth
2024-07-04 11:41     ` Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 14/15] tests/qtest: Free paths Akihiko Odaki
2024-06-27 13:37 ` [PATCH v2 15/15] tests/qtest: Free GThread Akihiko Odaki
2024-06-28 15:24   ` Peter Maydell
2024-07-01 20:11 ` [PATCH v2 00/15] Fix check-qtest-ppc64 sanitizer errors Michael S. Tsirkin
2024-07-01 22:23   ` BALATON Zoltan
2024-07-02  6:23     ` Thomas Huth
2024-07-04 11:37       ` 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=ZodPOTAcLo1XF4MB@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=aik@ozlabs.ru \
    --cc=akihiko.odaki@daynix.com \
    --cc=alex.bennee@linaro.org \
    --cc=balaton@eik.bme.hu \
    --cc=danielhb413@gmail.com \
    --cc=david@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=farosas@suse.de \
    --cc=harshpb@linux.ibm.com \
    --cc=jiaxun.yang@flygoat.com \
    --cc=jsnow@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wangyanan55@huawei.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).