On Wed, 9 Jan 2019 10:09:51 +0000 Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > On 09/01/2019 09:13, André Przywara wrote: > > On 09/01/2019 04:40, kbuild test robot wrote: > > > > Marc, Christoffer, > > > >> tree: > >> https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git > >> kvm-arm64/nv-wip-v5.0-rc1 head: > >> 688c386ca096f2c1f2eee386697586c88df5d5bc commit: > >> 2b1265c58a873d917e99ac762e243c1274481dbf [4/75] KVM: arm/arm64: > >> consolidate arch timer trap handlers config: arm-axm55xx_defconfig > >> (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian > >> 7.2.0-11) 7.2.0 reproduce: wget > >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross > >> -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout > >> 2b1265c58a873d917e99ac762e243c1274481dbf # save the > >> attached .config to linux build tree GCC_VERSION=7.2.0 make.cross > >> ARCH=arm > >> > >> All errors (new ones prefixed by >>): > > > > I was looking at this yesterday: It's a bit nasty, don't know a good > > solution beside bringing back this part of my original timer rework > > series. The problem is that those symbols contains the Aarch64 > > specific (instruction) encoding of the timer registers, plus we > > need the AArch32 encodings for 32-on-64 guests. > > Why? There is exactly one timer that needs trapping for AArch32 (the > EL1 physical timer). All we need is: > > - the SYS_AARCH32_CNTP_* encodings on 32bit > - some CPP magic to prevent the compilation from breaking Fair enough, if you are OK with this. I had something like this before, but it looked kind of hackish to me, so I was looking at some proper(TM) solution. > > > > That's why I used the generic UAPI encoding for the registers, > > because we only need *some* identification for them, it doesn't > > need to be something defined by the architecture. > > I disagree. By doing so, you're conflating userspace access and > trapping, which has proved to be a bad idea in the past. For example, > you'd end-up having both CVAL and TVAL in UAPI, which is not something > I'm keen to have. On the other hand, the trapping function do need to > be able to handle these. Fair enough, I was just *hoping* we can keep arch_timer.c clean of arch specific encodings. I can understand that with all the added complexity of the nested timers this is probably not feasible anymore. Cheers, Andre. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
