On Fri, Mar 10 2017 at 6:35:55 pm GMT, Will Deacon <will.deacon@xxxxxxx> wrote:
> On Fri, Mar 10, 2017 at 08:17:22AM +0000, Marc Zyngier wrote:
>> On Thu, Mar 09 2017 at 5:07:12 pm GMT, Mark Rutland <mark.rutland@xxxxxxx> wrote:
>> > Currently we duplicate effort in maintaining system register encodings across
>> > arm64's <asm/sysreg.h>, KVM's sysreg tables, and other places. This redundancy
>> > is unfortunate, and as encodings are encoded in-place without any mnemonic,
>> > this ends up more painful to read than necessary.
>> >
>> > This series ameliorates this by making <asm/sysreg.h> the canonical location
>> > for (architected) system register encodings, with other users building atop of
>> > this, e.g. with KVM deriving its sysreg table values from the common mnemonics.
>> >
>> > I've only attacked AArch64-native SYS encodings, and ignored CP{15,14}
>> > registers for now, but these could be handled similarly. Largely, I've stuck to
>> > only what KVM needs, though for the debug and perfmon groups it was easier to
>> > take the whole group from the ARM ARM than to filter them to only what KVM
>> > needed today.
>> >
>> > To verify that I haven't accidentally broken KVM, I've diffed sys_regs.o and
>> > sys_regs_generic_v8.o on a section-by-section basis before and after the series
>> > is applied. The .text, .data, and .rodata sections (and most others) are
>> > identical. The __bug_table section, and some .debug* sections differ, and this
>> > appears to be due to line numbers changing due to removed lines.
>> >
>> > One thing I wasn't sure how to address was banks of registers such as
>> > PMEVCNTR<n>_EL0. We currently enumerate all cases for our GICv3 definitions,
>> > but it seemed painful to expand ~30 cases for PMEVCNTR<n>_EL0 and friends, and
>> > for these I've made the macros take an 'n' parameter. It would be nice to be
>> > consistent either way, and I'm happy to expand those cases.
>> >
>> > I've pushed thes series out to a branch [1] based on v4.11-rc1. It looks like
>> > git rebase is also happy to apply the patches atop of the kvm-arm-for-4.11-rc2
>> > tag.
>>
>> I had a quick glance at this series, and this looks like a very good
>> piece of work - thanks for doing this.
>>
>> The next question is how do we merge this. Obviously, we can't split it
>> between trees, and this is very likely to clash with anything that we
>> will merge on the KVM side (the sysreg table is a popular place).
>>
>> Will, Catalin: Would it make sense to create a stable branch with these
>> patches, and merge it into both the arm64 and KVM trees? That'd make
>> things easier...
>
> I think the scope for conflict on our side is pretty high too, so a shared
> branch might be the best way to go. I don't want to branch just yet though,
> so I'll probably wait a week or so before setting something in stone.
Yup, that's absolutely fine. We're still mopping the outcome of the
merge window, and I won't queue any 4.12 material before another couple
of weeks. We can always point people to Mark's branch as a base for the
time being.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
