| Message ID | B8AC3E80E903784988AB3003E3E97330C0063545@dggemm510-mbs.china.huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote: > On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >>On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote: >>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c >>> index 049ee0a..359a782 100644 >>> --- a/arch/arm/mm/kasan_init.c >>> +++ b/arch/arm/mm/kasan_init.c >>> @@ -15,6 +15,7 @@ >>> #include <asm/proc-fns.h> >>> #include <asm/tlbflush.h> >>> #include <asm/cp15.h> >>> +#include <asm/kvm_hyp.h> >> >>No, please don't do that. You shouldn't have to include KVM stuff in >>unrelated code. Instead of adding stuff to kvm_hyp.h, move all the >>__ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this >>is where new definition should be added. > > Thanks for your review. You are right. It is better to move > __ACCESS_CP15* to cp15.h than to include kvm_hyp.h. But I don't think > it is a good idea to move registers definition which is used in > virtualization to cp15.h, Because there is no virtualization stuff in > cp15.h. It is not about virtualization at all. It is about what is a CP15 register and what is not. This file is called "cp15.h", not "cp15-except-virtualization-and-maybe-some-others.h". But at the end of the day, that's for Russell to decide. > > Here is the code which I tested on vexpress_a15 and vexpress_a9: > diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h > index dbdbce1..6db1f51 100644 > --- a/arch/arm/include/asm/cp15.h > +++ b/arch/arm/include/asm/cp15.h > @@ -64,6 +64,43 @@ > #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v))) > #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) > > +#ifdef CONFIG_ARM_LPAE > +#define TTBR0 __ACCESS_CP15_64(0, c2) > +#define TTBR1 __ACCESS_CP15_64(1, c2) > +#define PAR __ACCESS_CP15_64(0, c7) > +#else > +#define TTBR0 __ACCESS_CP15(c2, 0, c0, 0) > +#define TTBR1 __ACCESS_CP15(c2, 0, c0, 1) > +#define PAR __ACCESS_CP15(c7, 0, c4, 0) > +#endif Again: there is no point in not having these register encodings cohabiting. They are both perfectly defined in the architecture. Just suffix one (or even both) with their respective size, making it obvious which one you're talking about. Thanks, M.
On 09/11/17 18:36 Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote: >> On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >>>On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote: >>>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c >>>> index 049ee0a..359a782 100644 >>>> --- a/arch/arm/mm/kasan_init.c >>>> +++ b/arch/arm/mm/kasan_init.c >>>> @@ -15,6 +15,7 @@ >>>> #include <asm/proc-fns.h> >>>> #include <asm/tlbflush.h> >>>> #include <asm/cp15.h> >>>> +#include <asm/kvm_hyp.h> >>> >>>No, please don't do that. You shouldn't have to include KVM stuff in >>>unrelated code. Instead of adding stuff to kvm_hyp.h, move all the >>>__ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this >>>is where new definition should be added. >> >> Thanks for your review. You are right. It is better to move >> __ACCESS_CP15* to cp15.h than to include kvm_hyp.h. But I don't think >> it is a good idea to move registers definition which is used in >> virtualization to cp15.h, Because there is no virtualization stuff in >> cp15.h. > >It is not about virtualization at all. > >It is about what is a CP15 register and what is not. This file is called >"cp15.h", not "cp15-except-virtualization-and-maybe-some-others.h". But >at the end of the day, that's for Russell to decide. Thanks for your review. You are right, all __ACCESS_CP15* are cp15 registers. I splited normal cp15 register (such as TTBR0/TTBR1/SCTLR and so on) and virtualizaton cp15 registers(such as VTTBR/ CNTV_CVAL/HCR) because I didn't think we need use those virtualization cp15 registers in non virtualization system. But now I think all __ACCESS_CP15* move to cp15.h may be a better choise. >> >> Here is the code which I tested on vexpress_a15 and vexpress_a9: >> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h >> index dbdbce1..6db1f51 100644 >> --- a/arch/arm/include/asm/cp15.h >> +++ b/arch/arm/include/asm/cp15.h >> @@ -64,6 +64,43 @@ >> #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v))) >> #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) >> >> +#ifdef CONFIG_ARM_LPAE >> +#define TTBR0 __ACCESS_CP15_64(0, c2) >> +#define TTBR1 __ACCESS_CP15_64(1, c2) >> +#define PAR __ACCESS_CP15_64(0, c7) >> +#else >> +#define TTBR0 __ACCESS_CP15(c2, 0, c0, 0) >> +#define TTBR1 __ACCESS_CP15(c2, 0, c0, 1) >> +#define PAR __ACCESS_CP15(c7, 0, c4, 0) >> +#endif > >Again: there is no point in not having these register encodings >cohabiting. They are both perfectly defined in the architecture. Just >suffix one (or even both) with their respective size, making it obvious >which one you're talking about. I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR in to different way between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE. The following description is the reason: Here is the description come from DDI0406C2c_arm_architecture_reference_manual.pdf: B4.1.155 TTBR0, Translation Table Base Register 0, VMSA ... The Multiprocessing Extensions change the TTBR0 32-bit register format. The Large Physical Address Extension extends TTBR0 to a 64-bit register. In an implementation that includes the Large Physical Address Extension, TTBCR.EAE determines which TTBR0 format is used: EAE==0 32-bit format is used. TTBR0[63:32] are ignored. EAE==1 64-bit format is used. B4.1.156 TTBR1, Translation Table Base Register 1, VMSA ... The Multiprocessing Extensions change the TTBR0 32-bit register format. The Large Physical Address Extension extends TTBR1 to a 64-bit register. In an implementation that includes the Large Physical Address Extension, TTBCR.EAE determines which TTBR1 format is used: EAE==0 32-bit format is used. TTBR1[63:32] are ignored. EAE==1 64-bit format is used. B4.1.154 TTBCR, Translation Table Base Control Register, VMSA ... EAE, bit[31], if implementation includes the Large Physical Address Extension Extended Address Enable. The meanings of the possible values of this bit are: 0 Use the 32-bit translation system, with the Short-descriptor translation table format. In this case, the format of the TTBCR is as described in this section. 1 Use the 40-bit translation system, with the Long-descriptor translation table format. In this case, the format of the TTBCR is as described in TTBCR format when using the Long-descriptor translation table format on page B4-1692. B4.1.112 PAR, Physical Address Register, VMSA If the implementation includes the Large Physical Address Extension, the PAR is extended to be a 64-bit register and: * The 64-bit PAR is used: - when using the Long-descriptor translation table format - in an implementation that includes the Virtualization Extensions, for the result of an ATS1Cxx operation performed from Hyp mode. * The 32-bit PAR is used when using the Short-descriptor translation table format. In this case, PAR[63:32] is UNK/SBZP. Otherwise, the PAR is a 32-bit register.
On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote: > On 09/11/17 18:36 Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote: >>> On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >>>> On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote: >>>>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c >>>>> index 049ee0a..359a782 100644 >>>>> --- a/arch/arm/mm/kasan_init.c >>>>> +++ b/arch/arm/mm/kasan_init.c >>>>> @@ -15,6 +15,7 @@ >>>>> #include <asm/proc-fns.h> >>>>> #include <asm/tlbflush.h> >>>>> #include <asm/cp15.h> >>>>> +#include <asm/kvm_hyp.h> >>>> >>>> No, please don't do that. You shouldn't have to include KVM stuff in >>>> unrelated code. Instead of adding stuff to kvm_hyp.h, move all the >>>> __ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this >>>> is where new definition should be added. >>> >>> Thanks for your review. You are right. It is better to move >>> __ACCESS_CP15* to cp15.h than to include kvm_hyp.h. But I don't think >>> it is a good idea to move registers definition which is used in >>> virtualization to cp15.h, Because there is no virtualization stuff in >>> cp15.h. >> >> It is not about virtualization at all. >> >> It is about what is a CP15 register and what is not. This file is called >> "cp15.h", not "cp15-except-virtualization-and-maybe-some-others.h". But >> at the end of the day, that's for Russell to decide. > > Thanks for your review. > You are right, all __ACCESS_CP15* are cp15 registers. I splited normal cp15 register > (such as TTBR0/TTBR1/SCTLR and so on) and virtualizaton cp15 registers(such as VTTBR/ > CNTV_CVAL/HCR) because I didn't think we need use those virtualization cp15 registers > in non virtualization system. > > But now I think all __ACCESS_CP15* move to cp15.h may be a better choise. > >>> >>> Here is the code which I tested on vexpress_a15 and vexpress_a9: >>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h >>> index dbdbce1..6db1f51 100644 >>> --- a/arch/arm/include/asm/cp15.h >>> +++ b/arch/arm/include/asm/cp15.h >>> @@ -64,6 +64,43 @@ >>> #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v))) >>> #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) >>> >>> +#ifdef CONFIG_ARM_LPAE >>> +#define TTBR0 __ACCESS_CP15_64(0, c2) >>> +#define TTBR1 __ACCESS_CP15_64(1, c2) >>> +#define PAR __ACCESS_CP15_64(0, c7) >>> +#else >>> +#define TTBR0 __ACCESS_CP15(c2, 0, c0, 0) >>> +#define TTBR1 __ACCESS_CP15(c2, 0, c0, 1) >>> +#define PAR __ACCESS_CP15(c7, 0, c4, 0) >>> +#endif >> >> Again: there is no point in not having these register encodings >> cohabiting. They are both perfectly defined in the architecture. Just >> suffix one (or even both) with their respective size, making it obvious >> which one you're talking about. > > I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR in to different way > between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE. > The following description is the reason: > Here is the description come from DDI0406C2c_arm_architecture_reference_manual.pdf: [...] You're missing the point. TTBR0 existence as a 64bit CP15 register has nothing to do the kernel being compiled with LPAE or not. It has everything to do with the HW supporting LPAE, and it is the kernel's job to use the right accessor depending on how it is compiled. On a CPU supporting LPAE, both TTBR0 accessors are valid. It is the kernel that chooses to use one rather than the other. Also, if I follow your reasoning, why are you bothering defining PAR in the non-LPAE case? It is not used by anything, as far as I can see... Thanks, M.
>On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote: >> On 09/11/17 18:36 Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote: >>>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h >>>> index dbdbce1..6db1f51 100644 >>>> --- a/arch/arm/include/asm/cp15.h >>>> +++ b/arch/arm/include/asm/cp15.h >>>> @@ -64,6 +64,43 @@ >>>> #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v))) >>>> #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) >>>> >>>> +#ifdef CONFIG_ARM_LPAE >>>> +#define TTBR0 __ACCESS_CP15_64(0, c2) >>>> +#define TTBR1 __ACCESS_CP15_64(1, c2) >>>> +#define PAR __ACCESS_CP15_64(0, c7) >>>> +#else >>>> +#define TTBR0 __ACCESS_CP15(c2, 0, c0, 0) >>>> +#define TTBR1 __ACCESS_CP15(c2, 0, c0, 1) >>>> +#define PAR __ACCESS_CP15(c7, 0, c4, 0) >>>> +#endif >>> Again: there is no point in not having these register encodings >>> cohabiting. They are both perfectly defined in the architecture. Just >>> suffix one (or even both) with their respective size, making it obvious >>> which one you're talking about. >> >> I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR in to different way >> between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE. >> The following description is the reason: >> Here is the description come from DDI0406C2c_arm_architecture_reference_manual.pdf: >[...] > >You're missing the point. TTBR0 existence as a 64bit CP15 register has >nothing to do the kernel being compiled with LPAE or not. It has >everything to do with the HW supporting LPAE, and it is the kernel's job >to use the right accessor depending on how it is compiled. On a CPU >supporting LPAE, both TTBR0 accessors are valid. It is the kernel that >chooses to use one rather than the other. Thanks for your review. I don't think both TTBR0 accessors(64bit accessor and 32bit accessor) are valid on a CPU supporting LPAE which the LPAE is enabled. Here is the description come form DDI0406C2c_arm_architecture_reference_manual.pdf (=ARM® Architecture Reference Manual ARMv7-A and ARMv7-R edition) which you can get the document by google "ARM® Architecture Reference Manual ARMv7-A and ARMv7-R edition". 64-bit TTBR0 and TTBR1 format The bit assignments for the 64-bit implementations of TTBR0 and TTBR1 are identical, and are: Bits[63:56] UNK/SBZP. ASID, bits[55:48]: An ASID for the translation table base address. The TTBCR.A1 field selects either TTBR0.ASID or TTBR1.ASID. Bits[47:40] UNK/SBZP. BADDR, bits[39:x]: Translation table base address, bits[39:x]. Defining the translation table base address width on page B4-1698 describes how x is defined. The value of x determines the required alignment of the translation table, which must be aligned to 2x bytes. Bits[x-1:0] UNK/SBZP. ... To access a 64-bit TTBR0, software performs a 64-bit read or write of the CP15 registers with <CRm> set to c2 and <opc1> set to 0. For example: MRRC p15,0,<Rt>,<Rt2>, c2 ; Read 64-bit TTBR0 into Rt (low word) and Rt2 (high word) MCRR p15,0,<Rt>,<Rt2>, c2 ; Write Rt (low word) and Rt2 (high word) to 64-bit TTBR0 So, I think if you access TTBR0/TTBR1 on CPU supporting LPAE, you must use "mcrr/mrrc" instruction (__ACCESS_CP15_64). If you access TTBR0/TTBR1 on CPU supporting LPAE by "mcr/mrc" instruction which is 32bit version (__ACCESS_CP15), even if the CPU doesn't report error, you also lose the high or low 32bit of the TTBR0/TTBR1. >Also, if I follow your reasoning, why are you bothering defining PAR in >the non-LPAE case? It is not used by anything, as far as I can see... I don't use the PAR, I change the defining PAR just because I think it will be wrong in a non LPAE CPU.
On Thu, Nov 16 2017 at 3:07:54 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote: >>On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote: >>> On 09/11/17 18:36 Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >>>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" >>>> <liuwenliang@huawei.com> wrote: >>>>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h >>>>> index dbdbce1..6db1f51 100644 >>>>> --- a/arch/arm/include/asm/cp15.h >>>>> +++ b/arch/arm/include/asm/cp15.h >>>>> @@ -64,6 +64,43 @@ >>>>> #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : >>>>> "r" ((t)(v))) >>>>> #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) >>>>> >>>>> +#ifdef CONFIG_ARM_LPAE >>>>> +#define TTBR0 __ACCESS_CP15_64(0, c2) >>>>> +#define TTBR1 __ACCESS_CP15_64(1, c2) >>>>> +#define PAR __ACCESS_CP15_64(0, c7) >>>>> +#else >>>>> +#define TTBR0 __ACCESS_CP15(c2, 0, c0, 0) >>>>> +#define TTBR1 __ACCESS_CP15(c2, 0, c0, 1) >>>>> +#define PAR __ACCESS_CP15(c7, 0, c4, 0) >>>>> +#endif >>>> Again: there is no point in not having these register encodings >>>> cohabiting. They are both perfectly defined in the architecture. Just >>>> suffix one (or even both) with their respective size, making it obvious >>>> which one you're talking about. >>> >>> I am sorry that I didn't point why I need to define TTBR0/ >>> TTBR1/PAR in to different way >>> between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE. >>> The following description is the reason: >>> Here is the description come from >>> DDI0406C2c_arm_architecture_reference_manual.pdf: >>[...] >> >>You're missing the point. TTBR0 existence as a 64bit CP15 register has >>nothing to do the kernel being compiled with LPAE or not. It has >>everything to do with the HW supporting LPAE, and it is the kernel's job >>to use the right accessor depending on how it is compiled. On a CPU >>supporting LPAE, both TTBR0 accessors are valid. It is the kernel that >>chooses to use one rather than the other. > > Thanks for your review. I don't think both TTBR0 accessors(64bit > accessor and 32bit accessor) are valid on a CPU supporting LPAE which > the LPAE is enabled. Here is the description come form > DDI0406C2c_arm_architecture_reference_manual.pdf (=ARM® Architecture > Reference Manual ARMv7-A and ARMv7-R edition) which you can get the > document by google "ARM® Architecture Reference Manual ARMv7-A and > ARMv7-R edition". Trust me, from where I seat, I have a much better source than Google for that document. Who would have thought? Nothing in what you randomly quote invalids what I've been saying. And to show you what's wrong with your reasoning, let me describe a scenario, I have a non-LPAE kernel that runs on my system. It uses the 32bit version of the TTBRs. It turns out that this kernel runs under a hypervisor (KVM, Xen, or your toy of the day). The hypervisor context-switches vcpus without even looking at whether the configuration of that guest. It doesn't have to care. It just blindly uses the 64bit version of the TTBRs. The architecture *guarantees* that it works (it even works with a 32bit guest under a 64bit hypervisor). In your world, this doesn't work. I guess the architecture wins. > So, I think if you access TTBR0/TTBR1 on CPU supporting LPAE, you must > use "mcrr/mrrc" instruction (__ACCESS_CP15_64). If you access > TTBR0/TTBR1 on CPU supporting LPAE by "mcr/mrc" instruction which is > 32bit version (__ACCESS_CP15), even if the CPU doesn't report error, > you also lose the high or low 32bit of the TTBR0/TTBR1. It is not about "supporting LPAE". It is about using the accessor that makes sense in a particular context. Yes, the architecture allows you to do something stupid. Don't do it. It doesn't mean the accessors cannot be used, and I hope that my example above demonstrates it. Conclusion: I still stand by my request that both versions of TTBRs/PAR are described without depending on the kernel configuration, because this has nothing to do with the kernel configuration. Thanks, M.
diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h index dbdbce1..6db1f51 100644 --- a/arch/arm/include/asm/cp15.h +++ b/arch/arm/include/asm/cp15.h @@ -64,6 +64,43 @@ #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v))) #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) +#ifdef CONFIG_ARM_LPAE +#define TTBR0 __ACCESS_CP15_64(0, c2) +#define TTBR1 __ACCESS_CP15_64(1, c2) +#define PAR __ACCESS_CP15_64(0, c7) +#else +#define TTBR0 __ACCESS_CP15(c2, 0, c0, 0) +#define TTBR1 __ACCESS_CP15(c2, 0, c0, 1) +#define PAR __ACCESS_CP15(c7, 0, c4, 0) +#endif +#define MIDR __ACCESS_CP15(c0, 0, c0, 0) +#define CSSELR __ACCESS_CP15(c0, 2, c0, 0) +#define SCTLR __ACCESS_CP15(c1, 0, c0, 0) +#define CPACR __ACCESS_CP15(c1, 0, c0, 2) +#define TTBCR __ACCESS_CP15(c2, 0, c0, 2) +#define DACR __ACCESS_CP15(c3, 0, c0, 0) +#define DFSR __ACCESS_CP15(c5, 0, c0, 0) +#define IFSR __ACCESS_CP15(c5, 0, c0, 1) +#define ADFSR __ACCESS_CP15(c5, 0, c1, 0) +#define AIFSR __ACCESS_CP15(c5, 0, c1, 1) +#define DFAR __ACCESS_CP15(c6, 0, c0, 0) +#define IFAR __ACCESS_CP15(c6, 0, c0, 2) +#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0) +#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0) +#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0) +#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0) +#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4) +#define PRRR __ACCESS_CP15(c10, 0, c2, 0) +#define NMRR __ACCESS_CP15(c10, 0, c2, 1) +#define AMAIR0 __ACCESS_CP15(c10, 0, c3, 0) +#define AMAIR1 __ACCESS_CP15(c10, 0, c3, 1) +#define CID __ACCESS_CP15(c13, 0, c0, 1) +#define TID_URW __ACCESS_CP15(c13, 0, c0, 2) +#define TID_URO __ACCESS_CP15(c13, 0, c0, 3) +#define TID_PRIV __ACCESS_CP15(c13, 0, c0, 4) +#define CNTKCTL __ACCESS_CP15(c14, 0, c1, 0) +#define CNTHCTL __ACCESS_CP15(c14, 4, c1, 0) + extern unsigned long cr_alignment; /* defined in entry-armv.S */ static inline unsigned long get_cr(void) diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h index 14b5903..db8d8db 100644 --- a/arch/arm/include/asm/kvm_hyp.h +++ b/arch/arm/include/asm/kvm_hyp.h @@ -37,55 +37,25 @@ __val; \ }) -#define TTBR0 __ACCESS_CP15_64(0, c2) -#define TTBR1 __ACCESS_CP15_64(1, c2) #define VTTBR __ACCESS_CP15_64(6, c2) -#define PAR __ACCESS_CP15_64(0, c7) #define CNTV_CVAL __ACCESS_CP15_64(3, c14) #define CNTVOFF __ACCESS_CP15_64(4, c14) -#define MIDR __ACCESS_CP15(c0, 0, c0, 0) -#define CSSELR __ACCESS_CP15(c0, 2, c0, 0) #define VPIDR __ACCESS_CP15(c0, 4, c0, 0) #define VMPIDR __ACCESS_CP15(c0, 4, c0, 5) -#define SCTLR __ACCESS_CP15(c1, 0, c0, 0) -#define CPACR __ACCESS_CP15(c1, 0, c0, 2) #define HCR __ACCESS_CP15(c1, 4, c1, 0) #define HDCR __ACCESS_CP15(c1, 4, c1, 1) #define HCPTR __ACCESS_CP15(c1, 4, c1, 2) #define HSTR __ACCESS_CP15(c1, 4, c1, 3) -#define TTBCR __ACCESS_CP15(c2, 0, c0, 2) #define HTCR __ACCESS_CP15(c2, 4, c0, 2) #define VTCR __ACCESS_CP15(c2, 4, c1, 2) -#define DACR __ACCESS_CP15(c3, 0, c0, 0) -#define DFSR __ACCESS_CP15(c5, 0, c0, 0) -#define IFSR __ACCESS_CP15(c5, 0, c0, 1) -#define ADFSR __ACCESS_CP15(c5, 0, c1, 0) -#define AIFSR __ACCESS_CP15(c5, 0, c1, 1) #define HSR __ACCESS_CP15(c5, 4, c2, 0) -#define DFAR __ACCESS_CP15(c6, 0, c0, 0) -#define IFAR __ACCESS_CP15(c6, 0, c0, 2) #define HDFAR __ACCESS_CP15(c6, 4, c0, 0) #define HIFAR __ACCESS_CP15(c6, 4, c0, 2) #define HPFAR __ACCESS_CP15(c6, 4, c0, 4) -#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0) -#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0) -#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0) -#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0) -#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4) -#define PRRR __ACCESS_CP15(c10, 0, c2, 0) -#define NMRR __ACCESS_CP15(c10, 0, c2, 1) -#define AMAIR0 __ACCESS_CP15(c10, 0, c3, 0) -#define AMAIR1 __ACCESS_CP15(c10, 0, c3, 1) #define VBAR __ACCESS_CP15(c12, 0, c0, 0) -#define CID __ACCESS_CP15(c13, 0, c0, 1) -#define TID_URW __ACCESS_CP15(c13, 0, c0, 2) -#define TID_URO __ACCESS_CP15(c13, 0, c0, 3) -#define TID_PRIV __ACCESS_CP15(c13, 0, c0, 4) #define HTPIDR __ACCESS_CP15(c13, 4, c0, 2) -#define CNTKCTL __ACCESS_CP15(c14, 0, c1, 0) #define CNTV_CTL __ACCESS_CP15(c14, 0, c3, 1) -#define CNTHCTL __ACCESS_CP15(c14, 4, c1, 0) #define VFP_FPEXC __ACCESS_VFP(FPEXC)