From: David Gibson <david@gibson.dropbear.id.au>
To: Lucas Mateus Martins Araujo e Castro <lucas.araujo@eldorado.org.br>
Cc: bruno.larsen@eldorado.org.br, qemu-ppc@nongnu.org,
qemu-devel@nongnu.org, farosas@linux.ibm.com
Subject: Re: [RFC PATCH v2 1/2] target/ppc: Moved functions out of mmu-hash64
Date: Thu, 6 May 2021 12:03:10 +1000 [thread overview]
Message-ID: <YJNOXs2tD04vqGCD@yekko> (raw)
In-Reply-To: <6c67c7fb-a825-a469-a0dd-30c3c76c6472@eldorado.org.br>
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
On Wed, May 05, 2021 at 02:30:35PM -0300, Lucas Mateus Martins Araujo e Castro wrote:
>
> On 03/05/2021 01:24, David Gibson wrote:
> > On Fri, Apr 30, 2021 at 03:40:46PM -0300, Lucas Mateus Castro (alqotel) wrote:
> > > The functions ppc_store_lpcr, ppc_hash64_filter_pagesizes and
> > > ppc_hash64_unmap_hptes have been moved to mmu-misc.h since they are
> > > not needed in a !TCG context and mmu-hash64 should not be compiled
> > > in such situation.
> > >
> > > ppc_store_lpcr and ppc_hash64_filter_pagesizes are used by multiple
> > > functions, while ppc_hash64_unmap_hptes is used by rehash_hpt (in
> > > spapr_hcall.c).
> > Hmm.. looking at it, ppc_store_lpcr() (and helper_store_lpcr()) don't
> > really belong in this file at all. The LPCR has some things related
> > to the hash MMU, but plenty of others that don't. So, maybe
> > misc_helper.c? That might have to be moved again, since misc_helper
> > itself should probably mostly not be used for !TCG. But.. one thing
> > at a time.
>
> I tested here and compiling misc_helper.c with disable-tcg it's kind of
> complicated and it would require many changes in it, so for this patch
> just move it there and deal with it in a later patch?
Yes, sounds reasonable.
>
> > AFAICT the only user of ppc_hash64_filter_pagesizes() is in
> > spapr_caps.c. For now you can just move it next to the caller, it's
> > debatable whether it belongs more to PAPR or MMU code.
>
> Also I'm assuming the prototype should also be moved from
> "target/ppc/mmu-hash64.h" to "include/hw/ppc/spapr.h" (or some other
> spapr_*.h file), or should it be left in the original file?
Well, if you put it next to the caller you can make it static and
remove the prototype entirely.
>
> > ppc_hash64_unmap_hptes() is definitely TCG only and should stay where
> > it is. The call from rehash_hpt() can be solved because rehash_hpt()
> > itself is TCG only. I've already suggested splitting the TCG (well,
> > softmmu) only things out from spapr_hcall.c, so it might simplify
> > things to tackle that first.
> >
>
--
David Gibson | 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 --]
next prev parent reply other threads:[~2021-05-06 2:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-30 18:40 [RFC PATCH v2 0/2] hw/ppc: code motion to compile without TCG Lucas Mateus Castro (alqotel)
2021-04-30 18:40 ` [RFC PATCH v2 1/2] target/ppc: Moved functions out of mmu-hash64 Lucas Mateus Castro (alqotel)
2021-04-30 20:19 ` Fabiano Rosas
2021-05-03 4:24 ` David Gibson
2021-05-05 17:30 ` Lucas Mateus Martins Araujo e Castro
2021-05-06 2:03 ` David Gibson [this message]
2021-04-30 18:40 ` [RFC PATCH v2 2/2] hw/ppc: Moved TCG code to spapr_hcall_tcg Lucas Mateus Castro (alqotel)
2021-04-30 23:38 ` Fabiano Rosas
2021-05-03 4:35 ` David Gibson
2021-05-03 4:34 ` David Gibson
2021-05-04 18:14 ` Lucas Mateus Martins Araujo e Castro
2021-05-05 4:58 ` David Gibson
2021-04-30 18:54 ` [RFC PATCH v2 0/2] hw/ppc: code motion to compile without TCG no-reply
2021-05-03 22:21 ` Fabiano Rosas
2021-05-04 14:43 ` Bruno Piazera Larsen
2021-05-04 15:57 ` Lucas Mateus Martins Araujo e Castro
2021-05-05 4:42 ` David Gibson
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=YJNOXs2tD04vqGCD@yekko \
--to=david@gibson.dropbear.id.au \
--cc=bruno.larsen@eldorado.org.br \
--cc=farosas@linux.ibm.com \
--cc=lucas.araujo@eldorado.org.br \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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.