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 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).