Message ID | 20230213202927.28992-1-farosas@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | target/arm: Allow CONFIG_TCG=n builds | expand |
On Mon, 13 Feb 2023 at 20:31, Fabiano Rosas <farosas@suse.de> wrote: > > Hi, could someone take this? > > I rebased and put the two series together to simplify. I'm keeping it > up-to-date and tested while it doesn't go in. > > CI run here: https://gitlab.com/farosas/qemu/-/pipelines/776103500 > > Based on master. > Supersedes "target/arm: CONFIG_TCG=n part 1". I've taken patches 1-5 into target-arm.next. Patch 6 doesn't apply on top of my tree, which is unsurprising given that it's trying to move 9000+ lines of code in a single patch. That's so much I couldn't even figure out how to recreate the code movement locally. The diff is not very legible either. I think that patch needs to be restructured somehow so that it's a bit clearer that it's only doing code movement and a bit more likely that it might be possible to apply it without massive conflicts. thanks -- PMM
On Thu, 16 Feb 2023 at 16:19, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Mon, 13 Feb 2023 at 20:31, Fabiano Rosas <farosas@suse.de> wrote: > > > > Hi, could someone take this? > > > > I rebased and put the two series together to simplify. I'm keeping it > > up-to-date and tested while it doesn't go in. > > > > CI run here: https://gitlab.com/farosas/qemu/-/pipelines/776103500 > > > > Based on master. > > Supersedes "target/arm: CONFIG_TCG=n part 1". > > I've taken patches 1-5 into target-arm.next. I've also taken patches 18, 19, 22, 23, 24, which seemed like straightforward test fixes. thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On Mon, 13 Feb 2023 at 20:31, Fabiano Rosas <farosas@suse.de> wrote: >> >> Hi, could someone take this? >> >> I rebased and put the two series together to simplify. I'm keeping it >> up-to-date and tested while it doesn't go in. >> >> CI run here: https://gitlab.com/farosas/qemu/-/pipelines/776103500 >> >> Based on master. >> Supersedes "target/arm: CONFIG_TCG=n part 1". > > I've taken patches 1-5 into target-arm.next. > Patch 6 doesn't apply on top of my tree, which is unsurprising > given that it's trying to move 9000+ lines of code in a single > patch. That's so much I couldn't even figure out how to recreate > the code movement locally. The diff is not very legible either. Ugh, sorry about that. I forgot to apply --patience on this last resend. That diff should be just a sequence of 9k '-' lines and 9k '+' lines. I'll try to split it up, let's see how it goes, the ARMCPRegInfo arrays are huge, they might end up pulling everything with them.
On Thu, 16 Feb 2023 at 16:47, Fabiano Rosas <farosas@suse.de> wrote: > > Peter Maydell <peter.maydell@linaro.org> writes: > > > On Mon, 13 Feb 2023 at 20:31, Fabiano Rosas <farosas@suse.de> wrote: > >> > >> Hi, could someone take this? > >> > >> I rebased and put the two series together to simplify. I'm keeping it > >> up-to-date and tested while it doesn't go in. > >> > >> CI run here: https://gitlab.com/farosas/qemu/-/pipelines/776103500 > >> > >> Based on master. > >> Supersedes "target/arm: CONFIG_TCG=n part 1". > > > > I've taken patches 1-5 into target-arm.next. > > Patch 6 doesn't apply on top of my tree, which is unsurprising > > given that it's trying to move 9000+ lines of code in a single > > patch. That's so much I couldn't even figure out how to recreate > > the code movement locally. The diff is not very legible either. > > Ugh, sorry about that. I forgot to apply --patience on this last resend. > That diff should be just a sequence of 9k '-' lines and 9k '+' lines. > > I'll try to split it up, let's see how it goes, the ARMCPRegInfo arrays > are huge, they might end up pulling everything with them. If there are opportunities here to split some of the different categories of cpreg into their own file, the way we've done already with the debug registers, that might be a way to help structure it. For instance the PMU registers could probably all live in their own file, and the generic-timer regs similarly. thanks -- PMM
On 2/16/23 06:47, Fabiano Rosas wrote: > I'll try to split it up, let's see how it goes, the ARMCPRegInfo arrays > are huge, they might end up pulling everything with them. Feel free to make static functions non-static in e.g. internals.h or cpregs.h as necessary to allow an array to be moved without all of the helper functions at the same time. r~