On Mon, Apr 05, 2021 at 01:32:18PM +0000, Bruno Piazera Larsen wrote: > Hi all, > > The team I'm working on started to work on adding support for > building the ppc target with the disable-tcg option. However, we're > not quite sure on where to start with such a big patch. > > * Should we focus first on changing the .c files, so that it > will build when we finally patch the meson.build everything > build correctly? Or should we start by changing the meson > file, so that everyone agrees that the excluded files can > indeed be excluded? It's usually best to focus on logical changes, rather than file-by-file. That said, I'd probably suggest changing the .c files first, then changing the meson file. > * Should we first finish the whole series to then mail it, or > should we send one file at a time, as soon as we have them > ready? I'd lean towards building a whole series, since I think the individual file changes won't make a lot of sense on their own. That said, it's ok and encouraged to post a relatively early draft of the series as an RFC, so that the overall idea can be reviewed, even if it has obvious omissions (just mention them in the cover letter). > So far we're thinking we'll need to: > * change 6 files (arch_dump.c, machine.c, mmu-hash32.c, > mmu-hash64.c, mmu-radix64.c and meson.build); I'd expect mmu-*.c to be excluded. Those are softmmu implementations which shouldn't be used with KVM. It's possible there are a few helpers that will need to be extracted, though. You'll probably also need changes in hw/ppc/spapr_hcall.c and maybe some other parts of the spapr code: there are a number of hypercalls that we implement in qemu for TCG, but which are (and must be) implemented in KVM when KVM is in use. So, I expect you'll need to suppress compilation of h_enter, h_remove, h_protect, h_read and h_bulk_remove at least in the !TCG case. > * exclude 8 files from the build (dfp_helper.c, excp_helper.c, > fpu_helper.c, int_helper.c, mem_helper.c, misc_helper.c, * > translate.c, timebase_helper.c); That looks about right. > * create a new one that holds stubs. Sounds reasonable. > Does this sound about right? This is mostly guesswork based on how > x86, s390x and ARM are doing it. Sounds fine so far. -- 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