diff mbox series

[4/5] target/arm: Fill in ARMISARegisters for kvm32

Message ID 20181024113709.16599-5-richard.henderson@linaro.org
State Superseded
Headers show
Series target/arm: KVM vs ARMISARegisters | expand

Commit Message

Richard Henderson Oct. 24, 2018, 11:37 a.m. UTC
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

---
 target/arm/kvm32.c | 33 ++++++++++++++++++++++++++++-----
 1 file changed, 28 insertions(+), 5 deletions(-)

-- 
2.17.2

Comments

Peter Maydell Oct. 29, 2018, 3:13 p.m. UTC | #1
On 24 October 2018 at 12:37, Richard Henderson
<richard.henderson@linaro.org> wrote:
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

> ---

>  target/arm/kvm32.c | 33 ++++++++++++++++++++++++++++-----

>  1 file changed, 28 insertions(+), 5 deletions(-)


Reviewed-by: Peter Maydell <peter.maydell@linaro.org>


> +    /*

> +     * FIXME: There is not yet a way to read MVFR2.

> +     * Fortunately there is not yet anything in there that affects migration.

> +     */


We should bring that up with the KVM folks (cc'd)...

Presumably KVM_REG_ARM_VFP_MVFR2 should be 0x1005 and the code
in the kernel for handling this bit of the get/set-one-reg
ioctls needs to have code for it (including returning 0
for v7 CPUs, where this VMRS register encoding was UNPREDICTABLE).

thanks
-- PMM
Peter Maydell Oct. 29, 2018, 3:21 p.m. UTC | #2
On 29 October 2018 at 15:13, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 24 October 2018 at 12:37, Richard Henderson

> <richard.henderson@linaro.org> wrote:

>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

>> ---

>>  target/arm/kvm32.c | 33 ++++++++++++++++++++++++++++-----

>>  1 file changed, 28 insertions(+), 5 deletions(-)

>

> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

>

>> +    /*

>> +     * FIXME: There is not yet a way to read MVFR2.

>> +     * Fortunately there is not yet anything in there that affects migration.

>> +     */

>

> We should bring that up with the KVM folks (cc'd)...

>

> Presumably KVM_REG_ARM_VFP_MVFR2 should be 0x1005 and the code

> in the kernel for handling this bit of the get/set-one-reg

> ioctls needs to have code for it (including returning 0

> for v7 CPUs, where this VMRS register encoding was UNPREDICTABLE).


There's an argument for "fail the ioctl on v7 CPUs" rather than
"return 0"; I don't think I have a strong opinion, since in
practice userspace needs to handle the "doesn't exist" case
when it's running on an older kernel anyway.

thanks
-- PMM
Marc Zyngier Oct. 29, 2018, 3:40 p.m. UTC | #3
On 29/10/18 15:21, Peter Maydell wrote:
> On 29 October 2018 at 15:13, Peter Maydell <peter.maydell@linaro.org> wrote:

>> On 24 October 2018 at 12:37, Richard Henderson

>> <richard.henderson@linaro.org> wrote:

>>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

>>> ---

>>>  target/arm/kvm32.c | 33 ++++++++++++++++++++++++++++-----

>>>  1 file changed, 28 insertions(+), 5 deletions(-)

>>

>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

>>

>>> +    /*

>>> +     * FIXME: There is not yet a way to read MVFR2.

>>> +     * Fortunately there is not yet anything in there that affects migration.

>>> +     */

>>

>> We should bring that up with the KVM folks (cc'd)...

>>

>> Presumably KVM_REG_ARM_VFP_MVFR2 should be 0x1005 and the code

>> in the kernel for handling this bit of the get/set-one-reg

>> ioctls needs to have code for it (including returning 0

>> for v7 CPUs, where this VMRS register encoding was UNPREDICTABLE).

> 

> There's an argument for "fail the ioctl on v7 CPUs" rather than

> "return 0"; I don't think I have a strong opinion, since in

> practice userspace needs to handle the "doesn't exist" case

> when it's running on an older kernel anyway.


My temptation would be not to expose it at all when running on a v7
core, and return an error rather than zero.

The other issue is that we currently don't support running 32bit KVM on
any ARMv8 platform, as we strictly check the CPUs we want to run on (A7
and A15). I remember seeing patches that would allow any host core to be
used (similar to what we have on the 64bit side), but that never made it
in the tree.

If there is interest, I can revive this effort.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
Peter Maydell Oct. 29, 2018, 3:48 p.m. UTC | #4
On 29 October 2018 at 15:40, Marc Zyngier <marc.zyngier@arm.com> wrote:
> My temptation would be not to expose it at all when running on a v7

> core, and return an error rather than zero.

>

> The other issue is that we currently don't support running 32bit KVM on

> any ARMv8 platform, as we strictly check the CPUs we want to run on (A7

> and A15). I remember seeing patches that would allow any host core to be

> used (similar to what we have on the 64bit side), but that never made it

> in the tree.


Ah, that's convenient in some ways. It means we can define the
API to be "for v7, no register available via the ONE_REG API;
for v8, always present", provided we add the constant and the
support before we turn on any actual v8 CPUs for 32-bit KVM
(avoiding the awkward case of "v8 but kernel doesn't expose
MVFR2").

I don't think we particularly care about the 32-bit-kvm-on-v8
part, but it would be good to nail down this wrinkle so we don't
forget about it, maybe ?

thanks
-- PMM
Marc Zyngier Oct. 29, 2018, 3:56 p.m. UTC | #5
On 29/10/18 15:48, Peter Maydell wrote:
> On 29 October 2018 at 15:40, Marc Zyngier <marc.zyngier@arm.com> wrote:

>> My temptation would be not to expose it at all when running on a v7

>> core, and return an error rather than zero.

>>

>> The other issue is that we currently don't support running 32bit KVM on

>> any ARMv8 platform, as we strictly check the CPUs we want to run on (A7

>> and A15). I remember seeing patches that would allow any host core to be

>> used (similar to what we have on the 64bit side), but that never made it

>> in the tree.

> 

> Ah, that's convenient in some ways. It means we can define the

> API to be "for v7, no register available via the ONE_REG API;

> for v8, always present", provided we add the constant and the

> support before we turn on any actual v8 CPUs for 32-bit KVM

> (avoiding the awkward case of "v8 but kernel doesn't expose

> MVFR2").

> 

> I don't think we particularly care about the 32-bit-kvm-on-v8

> part, but it would be good to nail down this wrinkle so we don't

> forget about it, maybe ?


Absolutely. I'll write something up.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
diff mbox series

Patch

diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index da08f7aab8..f23cc77d9e 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -44,7 +44,7 @@  bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
      * and then query that CPU for the relevant ID registers.
      */
     int i, err = 0, fdarray[3];
-    uint32_t midr, id_pfr0, mvfr1;
+    uint32_t midr, id_pfr0;
     uint64_t features = 0;
 
     /* Old kernels may not know about the PREFERRED_TARGET ioctl: however
@@ -71,9 +71,32 @@  bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
 
     err |= read_sys_reg32(fdarray[2], &midr, ARM_CP15_REG32(0, 0, 0, 0));
     err |= read_sys_reg32(fdarray[2], &id_pfr0, ARM_CP15_REG32(0, 0, 1, 0));
-    err |= read_sys_reg32(fdarray[2], &mvfr1,
+
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.id_isar0,
+                          ARM_CP15_REG32(0, 0, 2, 0));
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.id_isar1,
+                          ARM_CP15_REG32(0, 0, 2, 1));
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.id_isar2,
+                          ARM_CP15_REG32(0, 0, 2, 2));
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.id_isar3,
+                          ARM_CP15_REG32(0, 0, 2, 3));
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.id_isar4,
+                          ARM_CP15_REG32(0, 0, 2, 4));
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.id_isar5,
+                          ARM_CP15_REG32(0, 0, 2, 5));
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.id_isar6,
+                          ARM_CP15_REG32(0, 0, 2, 7));
+
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.mvfr0,
+                          KVM_REG_ARM | KVM_REG_SIZE_U32 |
+                          KVM_REG_ARM_VFP | KVM_REG_ARM_VFP_MVFR0);
+    err |= read_sys_reg32(fdarray[2], &ahcf->isar.mvfr1,
                           KVM_REG_ARM | KVM_REG_SIZE_U32 |
                           KVM_REG_ARM_VFP | KVM_REG_ARM_VFP_MVFR1);
+    /*
+     * FIXME: There is not yet a way to read MVFR2.
+     * Fortunately there is not yet anything in there that affects migration.
+     */
 
     kvm_arm_destroy_scratch_host_vcpu(fdarray);
 
@@ -95,13 +118,13 @@  bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
     if (extract32(id_pfr0, 12, 4) == 1) {
         set_feature(&features, ARM_FEATURE_THUMB2EE);
     }
-    if (extract32(mvfr1, 20, 4) == 1) {
+    if (extract32(ahcf->isar.mvfr1, 20, 4) == 1) {
         set_feature(&features, ARM_FEATURE_VFP_FP16);
     }
-    if (extract32(mvfr1, 12, 4) == 1) {
+    if (extract32(ahcf->isar.mvfr1, 12, 4) == 1) {
         set_feature(&features, ARM_FEATURE_NEON);
     }
-    if (extract32(mvfr1, 28, 4) == 1) {
+    if (extract32(ahcf->isar.mvfr1, 28, 4) == 1) {
         /* FMAC support implies VFPv4 */
         set_feature(&features, ARM_FEATURE_VFP4);
     }