Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Catalin Marinas]

On Wed, Mar 29, 2017 at 09:41:47AM +0100, Will Deacon wrote:
> On Tue, Mar 28, 2017 at 10:29:31PM +0200, Christoffer Dall wrote:
> > On Tue, Mar 28, 2017 at 07:48:28PM +0100, Mark Rutland wrote:
> > > On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:
> > > > On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> > > > > On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> > > > 
> > > > > > 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.
> > > > 
> > > > Any further thoughts on this?
> > > > 
> > > > Christoffer has Acked the KVM bits, so if you're happy to do so for the
> > > > arm64 bits I can make a stable branch.
> > > 
> > > Looking around, it doesn't look like there's anything outside of arm64
> > > that'll conflict on the  changes, and git's happy to merge
> > > my changes with Suzuki's changes currently queued in arm64's
> > > for-next/core branch.
> > > 
> > > I think it would make sense for those to be in a common branch taken by
> > > both the arm64 and KVM trees, with the KVM-specific parts being taken by
> > > KVM alone atop of that.
> > > 
> > > Would everyone be happy with that?
> > 
> > I'm happy with that.
> > 
> > > 
> > > For reference, I've updated my branches so that arm64/common-sysreg only
> > > contains the common parts, with the KVM parts atop of that in
> > > kvm/common-sysreg.
> > > 
> > 
> > Will, Catalin:  Let me know if you're going to pull from common-sysreg
> > and I'll do the same and add the kvm patches above.
> 
> I think that's what we'll do, but Catalin's out this week (we're taking it
> in turns to go to work). I'd say go ahead and pull it into kvm if there
> aren't any conflicts. No need to wait for us.

I pulled it into the arm64 for-next/core as well (to be pushed out later
today).

-- 
Catalin
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Mark Rutland]

On Wed, Mar 29, 2017 at 09:41:47AM +0100, Will Deacon wrote:
> On Tue, Mar 28, 2017 at 10:29:31PM +0200, Christoffer Dall wrote:
> > On Tue, Mar 28, 2017 at 07:48:28PM +0100, Mark Rutland wrote:
> > > On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:

> > > I think it would make sense for those to be in a common branch taken by
> > > both the arm64 and KVM trees, with the KVM-specific parts being taken by
> > > KVM alone atop of that.
> > > 
> > > Would everyone be happy with that?
> > 
> > I'm happy with that.
> > 
> > > For reference, I've updated my branches so that arm64/common-sysreg only
> > > contains the common parts, with the KVM parts atop of that in
> > > kvm/common-sysreg.
> > 
> > Will, Catalin:  Let me know if you're going to pull from common-sysreg
> > and I'll do the same and add the kvm patches above.
> 
> I think that's what we'll do, but Catalin's out this week (we're taking it
> in turns to go to work). I'd say go ahead and pull it into kvm if there
> aren't any conflicts. No need to wait for us.
> 
> Mark -- those branches are stable, right?

They are now. I will not touch either branch.

Thanks,
Mark.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Will Deacon]

On Tue, Mar 28, 2017 at 10:29:31PM +0200, Christoffer Dall wrote:
> On Tue, Mar 28, 2017 at 07:48:28PM +0100, Mark Rutland wrote:
> > On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:
> > > On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> > > > On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> > > 
> > > > > 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.
> > > 
> > > Any further thoughts on this?
> > > 
> > > Christoffer has Acked the KVM bits, so if you're happy to do so for the
> > > arm64 bits I can make a stable branch.
> > 
> > Looking around, it doesn't look like there's anything outside of arm64
> > that'll conflict on the  changes, and git's happy to merge
> > my changes with Suzuki's changes currently queued in arm64's
> > for-next/core branch.
> > 
> > I think it would make sense for those to be in a common branch taken by
> > both the arm64 and KVM trees, with the KVM-specific parts being taken by
> > KVM alone atop of that.
> > 
> > Would everyone be happy with that?
> 
> I'm happy with that.
> 
> > 
> > For reference, I've updated my branches so that arm64/common-sysreg only
> > contains the common parts, with the KVM parts atop of that in
> > kvm/common-sysreg.
> > 
> 
> Will, Catalin:  Let me know if you're going to pull from common-sysreg
> and I'll do the same and add the kvm patches above.

I think that's what we'll do, but Catalin's out this week (we're taking it
in turns to go to work). I'd say go ahead and pull it into kvm if there
aren't any conflicts. No need to wait for us.

Mark -- those branches are stable, right?

Will
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Christoffer Dall]

On Tue, Mar 28, 2017 at 07:48:28PM +0100, Mark Rutland wrote:
> On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:
> > On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> > > On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> > 
> > > > 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.
> > 
> > Any further thoughts on this?
> > 
> > Christoffer has Acked the KVM bits, so if you're happy to do so for the
> > arm64 bits I can make a stable branch.
> 
> Looking around, it doesn't look like there's anything outside of arm64
> that'll conflict on the  changes, and git's happy to merge
> my changes with Suzuki's changes currently queued in arm64's
> for-next/core branch.
> 
> I think it would make sense for those to be in a common branch taken by
> both the arm64 and KVM trees, with the KVM-specific parts being taken by
> KVM alone atop of that.
> 
> Would everyone be happy with that?

I'm happy with that.

> 
> For reference, I've updated my branches so that arm64/common-sysreg only
> contains the common parts, with the KVM parts atop of that in
> kvm/common-sysreg.
> 

Will, Catalin:  Let me know if you're going to pull from common-sysreg
and I'll do the same and add the kvm patches above.

Thanks for preparing the patches.
-Christoffer
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Mark Rutland]

On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:
> On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> > On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> 
> > > 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.
> 
> Any further thoughts on this?
> 
> Christoffer has Acked the KVM bits, so if you're happy to do so for the
> arm64 bits I can make a stable branch.

Looking around, it doesn't look like there's anything outside of arm64
that'll conflict on the  changes, and git's happy to merge
my changes with Suzuki's changes currently queued in arm64's
for-next/core branch.

I think it would make sense for those to be in a common branch taken by
both the arm64 and KVM trees, with the KVM-specific parts being taken by
KVM alone atop of that.

Would everyone be happy with that?

For reference, I've updated my branches so that arm64/common-sysreg only
contains the common parts, with the KVM parts atop of that in
kvm/common-sysreg.

Thanks,
Mark.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Mark Rutland]

Hi,

On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:

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

Any further thoughts on this?

Christoffer has Acked the KVM bits, so if you're happy to do so for the
arm64 bits I can make a stable branch.

Thanks,
Mark.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Christoffer Dall]

On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> On Thu, Mar 09 2017 at  5:07:12 pm GMT, Mark Rutland  
> wrote:
> > Currently we duplicate effort in maintaining system register encodings 
> > across
> > arm64's , 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  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_EL0. We currently enumerate all cases for our GICv3 definitions,
> > but it seemed painful to expand ~30 cases for PMEVCNTR_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.

Agreed.  You can add my acked-by on all the KVM patches if you please.

Thanks,
-Christoffer
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Marc Zyngier]

On Fri, Mar 10 2017 at  6:35:55 pm GMT, Will Deacon  wrote:
> On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
>> On Thu, Mar 09 2017 at  5:07:12 pm GMT, Mark Rutland  
>> wrote:
>> > Currently we duplicate effort in maintaining system register encodings 
>> > across
>> > arm64's , 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  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_EL0. We currently enumerate all cases for our GICv3 
>> > definitions,
>> > but it seemed painful to expand ~30 cases for PMEVCNTR_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@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Mark Rutland]

On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> > On Thu, Mar 09 2017 at  5:07:12 pm GMT, Mark Rutland  
> > wrote:
> > 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.

Sure thing.

Let me know if you want me to rebase this, otherwise I'll leave my
current branch as-is.

Thanks,
Mark.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Will Deacon]

On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> On Thu, Mar 09 2017 at  5:07:12 pm GMT, Mark Rutland  
> wrote:
> > Currently we duplicate effort in maintaining system register encodings 
> > across
> > arm64's , 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  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_EL0. We currently enumerate all cases for our GICv3 definitions,
> > but it seemed painful to expand ~30 cases for PMEVCNTR_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.

Will
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 00/15] arm64/kvm: use common sysreg definitions

[Marc Zyngier]

On Thu, Mar 09 2017 at  5:07:12 pm GMT, Mark Rutland  
wrote:
> Currently we duplicate effort in maintaining system register encodings across
> arm64's , 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  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_EL0. We currently enumerate all cases for our GICv3 definitions,
> but it seemed painful to expand ~30 cases for PMEVCNTR_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...

Thanks,

M.
-- 
Jazz is not dead, it just smell funny.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 00/15] arm64/kvm: use common sysreg definitions

[Mark Rutland]

Currently we duplicate effort in maintaining system register encodings across
arm64's , 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  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_EL0. We currently enumerate all cases for our GICv3 definitions,
but it seemed painful to expand ~30 cases for PMEVCNTR_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.

Thanks,
Mark.

Since RFC [2]:
* Rebase to v4.11-rc1, solving a trivial conflict.
* Handle the physical counter registers.
* Verified section differences again.

Thanks,
Mark.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git 
arm64/common-sysreg
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/484693.html

Mark Rutland (15):
  arm64: sysreg: sort by encoding
  arm64: sysreg: add debug system registers
  arm64: sysreg: add performance monitor registers
  arm64: sysreg: subsume GICv3 sysreg definitions
  arm64: sysreg: add physical timer registers
  arm64: sysreg: add register encodings used by KVM
  arm64: sysreg: add Set/Way sys encodings
  KVM: arm64: add SYS_DESC()
  KVM: arm64: Use common debug sysreg definitions
  KVM: arm64: Use common performance monitor sysreg definitions
  KVM: arm64: Use common GICv3 sysreg definitions
  KVM: arm64: Use common physical timer sysreg definitions
  KVM: arm64: use common invariant sysreg definitions
  KVM: arm64: Use common sysreg definitions
  KVM: arm64: Use common Set/Way sys definitions

 arch/arm64/include/asm/arch_gicv3.h  |  81 ++--
 arch/arm64/include/asm/sysreg.h  | 162 +++-
 arch/arm64/kernel/head.S |   8 +-
 arch/arm64/kvm/sys_regs.c| 358 +++
 arch/arm64/kvm/sys_regs.h|   5 +
 arch/arm64/kvm/sys_regs_generic_v8.c |   4 +-
 6 files changed, 284 insertions(+), 334 deletions(-)

-- 
1.9.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm