[Qemu-devel] [PATCH 0/2] target-arm: "any" CPUs for system-mode

[Qemu-devel] [PATCH 0/2] target-arm: "any" CPUs for system-mode

[meadori]

From: Meador Inge <meadori@codesourcery.com>

This patch series opens up the "any" CPU for system-mode and
adds a new "any" variant named "anyvfp" that initializes the
FP coprocessors as well.  The "any" CPUs are very useful
for quickly testing a range of applications that have been
compiled with different settings using the same QEMU command
line.

Meador Inge (2):
  target-arm: Allow CPU "any" for system-mode emulation
  target-arm: Add "anyvfp" CPU

 target-arm/cpu.c | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

-- 
1.8.1.1

[Qemu-devel] [PATCH 1/2] target-arm: Allow CPU "any" for system-mode emulation

[meadori]

From: Meador Inge <meadori@codesourcery.com>

The "any" CPU is useful for cases where the system-mode
emulator is being used to work with a wide array of
bare-metal C/C++ applications that have been compiled
in different ways.

Signed-off-by: Meador Inge <meadori@codesourcery.com>
---
 target-arm/cpu.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 80669a6..3665f6b 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -1243,7 +1243,6 @@ static void pxa270c5_initfn(Object *obj)
     cpu->reset_sctlr = 0x00000078;
 }
 
-#ifdef CONFIG_USER_ONLY
 static void arm_any_initfn(Object *obj)
 {
     ARMCPU *cpu = ARM_CPU(obj);
@@ -1258,7 +1257,6 @@ static void arm_any_initfn(Object *obj)
     set_feature(&cpu->env, ARM_FEATURE_CRC);
     cpu->midr = 0xffffffff;
 }
-#endif
 
 #endif /* !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64) */
 
@@ -1305,10 +1303,8 @@ static const ARMCPUInfo arm_cpus[] = {
     { .name = "pxa270-b1",   .initfn = pxa270b1_initfn },
     { .name = "pxa270-c0",   .initfn = pxa270c0_initfn },
     { .name = "pxa270-c5",   .initfn = pxa270c5_initfn },
-#ifdef CONFIG_USER_ONLY
     { .name = "any",         .initfn = arm_any_initfn },
 #endif
-#endif
     { .name = NULL }
 };
 
-- 
1.8.1.1

Re: [Qemu-devel] [PATCH 1/2] target-arm: Allow CPU "any" for system-mode emulation

[Peter Crosthwaite]

On Mon, Jul 6, 2015 at 11:53 AM,  <meadori@codesourcery.com> wrote:
> From: Meador Inge <meadori@codesourcery.com>
>
> The "any" CPU is useful for cases where the system-mode
> emulator is being used to work with a wide array of
> bare-metal C/C++ applications that have been compiled
> in different ways.
>

What is the system being created in this case though? Are you using -M
virt and can it reliably create usable systems with CPU type
substitutions?

Regards,
Peter

> Signed-off-by: Meador Inge <meadori@codesourcery.com>
> ---
>  target-arm/cpu.c | 4 ----
>  1 file changed, 4 deletions(-)
>
> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> index 80669a6..3665f6b 100644
> --- a/target-arm/cpu.c
> +++ b/target-arm/cpu.c
> @@ -1243,7 +1243,6 @@ static void pxa270c5_initfn(Object *obj)
>      cpu->reset_sctlr = 0x00000078;
>  }
>
> -#ifdef CONFIG_USER_ONLY
>  static void arm_any_initfn(Object *obj)
>  {
>      ARMCPU *cpu = ARM_CPU(obj);
> @@ -1258,7 +1257,6 @@ static void arm_any_initfn(Object *obj)
>      set_feature(&cpu->env, ARM_FEATURE_CRC);
>      cpu->midr = 0xffffffff;
>  }
> -#endif
>
>  #endif /* !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64) */
>
> @@ -1305,10 +1303,8 @@ static const ARMCPUInfo arm_cpus[] = {
>      { .name = "pxa270-b1",   .initfn = pxa270b1_initfn },
>      { .name = "pxa270-c0",   .initfn = pxa270c0_initfn },
>      { .name = "pxa270-c5",   .initfn = pxa270c5_initfn },
> -#ifdef CONFIG_USER_ONLY
>      { .name = "any",         .initfn = arm_any_initfn },
>  #endif
> -#endif
>      { .name = NULL }
>  };
>
> --
> 1.8.1.1
>
>

[Qemu-devel] [PATCH 2/2] target-arm: Add "anyvfp" CPU

[meadori]

From: Meador Inge <meadori@codesourcery.com>

This patch adds support for `-cpu anyvfp`, which is just
like `-cpu any`, but enables the coprocessors by default.
This is useful for working with a wide range of bare-metal
C/C++ applications that have been compiled in different
ways and assume the coprocessor has been enabled already.

Original patch by Daniel Jacobowitz.

Signed-off-by: Meador Inge <meadori@codesourcery.com>
---
 target-arm/cpu.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 3665f6b..2a00e73 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -181,7 +181,14 @@ static void arm_cpu_reset(CPUState *s)
         env->regs[15] = 0xFFFF0000;
     }
 
-    env->vfp.xregs[ARM_VFP_FPEXC] = 0;
+    /* For -cpu anyvfp, enable coprocessors by default.  Useful for
+       testing code that expects something else to turn on the
+       coprocessor.  */
+    if (cpu->midr == 0xfffffffe) {
+        env->vfp.xregs[ARM_VFP_FPEXC] = 1 << 30;
+    } else {
+        env->vfp.xregs[ARM_VFP_FPEXC] = 0;
+    }
 #endif
     set_flush_to_zero(1, &env->vfp.standard_fp_status);
     set_flush_inputs_to_zero(1, &env->vfp.standard_fp_status);
@@ -1258,6 +1265,13 @@ static void arm_any_initfn(Object *obj)
     cpu->midr = 0xffffffff;
 }
 
+static void arm_anyvfp_initfn(Object *obj)
+{
+    ARMCPU *cpu = ARM_CPU(obj);
+    arm_any_initfn(obj);
+    cpu->midr = 0xfffffffe;
+}
+
 #endif /* !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64) */
 
 typedef struct ARMCPUInfo {
@@ -1304,6 +1318,7 @@ static const ARMCPUInfo arm_cpus[] = {
     { .name = "pxa270-c0",   .initfn = pxa270c0_initfn },
     { .name = "pxa270-c5",   .initfn = pxa270c5_initfn },
     { .name = "any",         .initfn = arm_any_initfn },
+    { .name = "anyvfp",      .initfn = arm_anyvfp_initfn },
 #endif
     { .name = NULL }
 };
-- 
1.8.1.1

Re: [Qemu-devel] [PATCH 2/2] target-arm: Add "anyvfp" CPU

[Peter Crosthwaite]

On Mon, Jul 6, 2015 at 11:53 AM,  <meadori@codesourcery.com> wrote:
> From: Meador Inge <meadori@codesourcery.com>
>
> This patch adds support for `-cpu anyvfp`, which is just
> like `-cpu any`, but enables the coprocessors by default.

So a better way to do this is via QOM properties. You can propertyify
VFP support on the QOM type ARMCPU then users can use -global to set
in on the command line. You could do this for any number of ARM CPU
features you care about to create the combos you want on the command
line rather than having an in tree CPU def for special cases.

Have a look at the way the has_el3 feature is handled as a CPU property.

> This is useful for working with a wide range of bare-metal
> C/C++ applications that have been compiled in different
> ways and assume the coprocessor has been enabled already.
>
> Original patch by Daniel Jacobowitz.

Do you have originals in a git with the author SOBs that you can just
amend with your own editor notes?

>
> Signed-off-by: Meador Inge <meadori@codesourcery.com>
> ---
>  target-arm/cpu.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> index 3665f6b..2a00e73 100644
> --- a/target-arm/cpu.c
> +++ b/target-arm/cpu.c
> @@ -181,7 +181,14 @@ static void arm_cpu_reset(CPUState *s)
>          env->regs[15] = 0xFFFF0000;
>      }
>
> -    env->vfp.xregs[ARM_VFP_FPEXC] = 0;
> +    /* For -cpu anyvfp, enable coprocessors by default.  Useful for
> +       testing code that expects something else to turn on the
> +       coprocessor.  */

Comment style should be this:

/* multi line comment style
 * needs *'s on each line.
 */

> +    if (cpu->midr == 0xfffffffe) {
> +        env->vfp.xregs[ARM_VFP_FPEXC] = 1 << 30;
> +    } else {
> +        env->vfp.xregs[ARM_VFP_FPEXC] = 0;
> +    }
>  #endif
>      set_flush_to_zero(1, &env->vfp.standard_fp_status);
>      set_flush_inputs_to_zero(1, &env->vfp.standard_fp_status);
> @@ -1258,6 +1265,13 @@ static void arm_any_initfn(Object *obj)
>      cpu->midr = 0xffffffff;
>  }
>
> +static void arm_anyvfp_initfn(Object *obj)
> +{
> +    ARMCPU *cpu = ARM_CPU(obj);
> +    arm_any_initfn(obj);
> +    cpu->midr = 0xfffffffe;


Do you need to set the MIDR like this or is it just a means to
communicate feature support?

Regards,
Peter

> +}
> +
>  #endif /* !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64) */
>
>  typedef struct ARMCPUInfo {
> @@ -1304,6 +1318,7 @@ static const ARMCPUInfo arm_cpus[] = {
>      { .name = "pxa270-c0",   .initfn = pxa270c0_initfn },
>      { .name = "pxa270-c5",   .initfn = pxa270c5_initfn },
>      { .name = "any",         .initfn = arm_any_initfn },
> +    { .name = "anyvfp",      .initfn = arm_anyvfp_initfn },
>  #endif
>      { .name = NULL }
>  };
> --
> 1.8.1.1
>
>

Re: [Qemu-devel] [PATCH 2/2] target-arm: Add "anyvfp" CPU

[Meador Inge]

On Mon, Jul 06, 2015 at 03:00:20PM -0700, Peter Crosthwaite wrote:

> So a better way to do this is via QOM properties. You can propertyify
> VFP support on the QOM type ARMCPU then users can use -global to set
> in on the command line. You could do this for any number of ARM CPU
> features you care about to create the combos you want on the command
> line rather than having an in tree CPU def for special cases.
> 
> Have a look at the way the has_el3 feature is handled as a CPU property.

I will look into that.  Thank you.

> Do you have originals in a git with the author SOBs that you can just
> amend with your own editor notes?

Unfortunately for this case, no.  This is a very hold patch that was
originally in an SVN mirror.

-- Meador

Re: [Qemu-devel] [PATCH 2/2] target-arm: Add "anyvfp" CPU

[Peter Crosthwaite]

On Mon, Jul 13, 2015 at 1:21 PM, Meador Inge <meadori@codesourcery.com> wrote:
> On Mon, Jul 06, 2015 at 03:00:20PM -0700, Peter Crosthwaite wrote:
>
>> So a better way to do this is via QOM properties. You can propertyify
>> VFP support on the QOM type ARMCPU then users can use -global to set
>> in on the command line. You could do this for any number of ARM CPU
>> features you care about to create the combos you want on the command
>> line rather than having an in tree CPU def for special cases.
>>
>> Have a look at the way the has_el3 feature is handled as a CPU property.
>
> I will look into that.  Thank you.
>
>> Do you have originals in a git with the author SOBs that you can just
>> amend with your own editor notes?
>
> Unfortunately for this case, no.  This is a very hold patch that was
> originally in an SVN mirror.
>

Ok, not a problem.

Regards,
Peter

> -- Meador
>

Re: [Qemu-devel] [PATCH 2/2] target-arm: Add "anyvfp" CPU

[Peter Maydell]

On 6 July 2015 at 19:53,  <meadori@codesourcery.com> wrote:
> From: Meador Inge <meadori@codesourcery.com>
>
> This patch adds support for `-cpu anyvfp`, which is just
> like `-cpu any`, but enables the coprocessors by default.
> This is useful for working with a wide range of bare-metal
> C/C++ applications that have been compiled in different
> ways and assume the coprocessor has been enabled already.

I'm not convinced. System mode gives you a bare metal
system -- it's the bare metal app's job to enable
VFP if it wants to use it. If your bare metal app
doesn't do that then it is broken.

Alternatively you can use a firmware blob which
does enough setup for whatever environment your
code is expecting.

I really don't want to get QEMU into the business of
providing random ad-hoc execution environments for
things. It's hard enough maintaining the Linux boot
loader code...

thanks
-- PMM

Re: [Qemu-devel] [PATCH 2/2] target-arm: Add "anyvfp" CPU

[Meador Inge]

On Mon, Jul 06, 2015 at 11:31:37PM +0100, Peter Maydell wrote:

> I'm not convinced. System mode gives you a bare metal
> system -- it's the bare metal app's job to enable
> VFP if it wants to use it. If your bare metal app
> doesn't do that then it is broken.

Fair enough.  I knew this patch would be a bit of a stretch :-)

Thanks.

-- Meador

Re: [Qemu-devel] [PATCH 0/2] target-arm: "any" CPUs for system-mode

[Peter Maydell]

On 6 July 2015 at 19:53,  <meadori@codesourcery.com> wrote:
> From: Meador Inge <meadori@codesourcery.com>
>
> This patch series opens up the "any" CPU for system-mode and
> adds a new "any" variant named "anyvfp" that initializes the
> FP coprocessors as well.

We deliberately removed cpu "any" for system mode in
commit f5f6d38b7458b8a back in 2013; I think the rationale
for its removal still holds. If you're emulating a system
you're emulating a specific system and you get a real
CPU. A CPU with no impdef sysregs or initialized feature
and ID registers is broken...

thanks
-- PMM

Re: [Qemu-devel] [PATCH 0/2] target-arm: "any" CPUs for system-mode

[Peter Crosthwaite]

On Mon, Jul 6, 2015 at 3:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 6 July 2015 at 19:53,  <meadori@codesourcery.com> wrote:
>> From: Meador Inge <meadori@codesourcery.com>
>>
>> This patch series opens up the "any" CPU for system-mode and
>> adds a new "any" variant named "anyvfp" that initializes the
>> FP coprocessors as well.
>
> We deliberately removed cpu "any" for system mode in
> commit f5f6d38b7458b8a back in 2013; I think the rationale
> for its removal still holds. If you're emulating a system
> you're emulating a specific system and you get a real
> CPU. A CPU with no impdef sysregs or initialized feature
> and ID registers is broken...

You can still have a CPU+RAM only machine model, load elfs and get
meaningful result on a debugger. I wonder though if linux-user can be
re-purposed for this?

Regards,
Peter

>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH 0/2] target-arm: "any" CPUs for system-mode

[Peter Maydell]

On 6 July 2015 at 23:42, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> On Mon, Jul 6, 2015 at 3:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 6 July 2015 at 19:53,  <meadori@codesourcery.com> wrote:
>>> From: Meador Inge <meadori@codesourcery.com>
>>>
>>> This patch series opens up the "any" CPU for system-mode and
>>> adds a new "any" variant named "anyvfp" that initializes the
>>> FP coprocessors as well.
>>
>> We deliberately removed cpu "any" for system mode in
>> commit f5f6d38b7458b8a back in 2013; I think the rationale
>> for its removal still holds. If you're emulating a system
>> you're emulating a specific system and you get a real
>> CPU. A CPU with no impdef sysregs or initialized feature
>> and ID registers is broken...
>
> You can still have a CPU+RAM only machine model, load elfs and get
> meaningful result on a debugger.

Yeah, but what does "any" get you over just going ahead
and specifying your CPU type? What interrupt controller
should the "any" CPU type have? Generic timers? Etc.

There isn't zero utility there, but I don't really think
there's enough to justify cluttering up QEMU with when
"-cpu cortex-a15" is not very much more to type, and
has the advantage of being something that actually
exists in reality.

-- PMM

Re: [Qemu-devel] [PATCH 0/2] target-arm: "any" CPUs for system-mode

[Peter Crosthwaite]

On Mon, Jul 6, 2015 at 3:49 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 6 July 2015 at 23:42, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>> On Mon, Jul 6, 2015 at 3:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 6 July 2015 at 19:53,  <meadori@codesourcery.com> wrote:
>>>> From: Meador Inge <meadori@codesourcery.com>
>>>>
>>>> This patch series opens up the "any" CPU for system-mode and
>>>> adds a new "any" variant named "anyvfp" that initializes the
>>>> FP coprocessors as well.
>>>
>>> We deliberately removed cpu "any" for system mode in
>>> commit f5f6d38b7458b8a back in 2013; I think the rationale
>>> for its removal still holds. If you're emulating a system
>>> you're emulating a specific system and you get a real
>>> CPU. A CPU with no impdef sysregs or initialized feature
>>> and ID registers is broken...
>>
>> You can still have a CPU+RAM only machine model, load elfs and get
>> meaningful result on a debugger.
>
> Yeah, but what does "any" get you over just going ahead
> and specifying your CPU type? What interrupt controller
> should the "any" CPU type have? Generic timers? Etc.
>

None and none. You are only interested in CPU internal state with no IO at all.

> There isn't zero utility there, but I don't really think
> there's enough to justify cluttering up QEMU with when
> "-cpu cortex-a15" is not very much more to type, and
> has the advantage of being something that actually
> exists in reality.

There is a clean definition of an ARM CPU without any IO however which
has utility in compiler testing.

Regards,
Peter

>
> -- PMM
>

Re: [Qemu-devel] [PATCH 0/2] target-arm: "any" CPUs for system-mode

[Meador Inge]

On Mon, Jul 06, 2015 at 04:05:46PM -0700, Peter Crosthwaite wrote:

> On Mon, Jul 6, 2015 at 3:49 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 6 July 2015 at 23:42, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> >> On Mon, Jul 6, 2015 at 3:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>> On 6 July 2015 at 19:53,  <meadori@codesourcery.com> wrote:
> >>>> From: Meador Inge <meadori@codesourcery.com>
> >>>>
> >>>> This patch series opens up the "any" CPU for system-mode and
> >>>> adds a new "any" variant named "anyvfp" that initializes the
> >>>> FP coprocessors as well.
> >>>
> >>> We deliberately removed cpu "any" for system mode in
> >>> commit f5f6d38b7458b8a back in 2013; I think the rationale
> >>> for its removal still holds. If you're emulating a system
> >>> you're emulating a specific system and you get a real
> >>> CPU. A CPU with no impdef sysregs or initialized feature
> >>> and ID registers is broken...
> >>
> >> You can still have a CPU+RAM only machine model, load elfs and get
> >> meaningful result on a debugger.
> >
> > Yeah, but what does "any" get you over just going ahead
> > and specifying your CPU type? What interrupt controller
> > should the "any" CPU type have? Generic timers? Etc.
> >
> 
> None and none. You are only interested in CPU internal state with no IO at all.

Exactly.  We have a use-case where QEMU acts as basically an ISS and we
only care about architecture level support.  So, someone compiles their
application with various options (-march=armv7-a, -march=arv5te, etc...)
and runs those through GDB that connects to the QEMU GDB stub.  From
the QEMU side we can launch an instance with '-cpu any' and expect most
applications to run on it regardless of how it was built with GCC.

This is a reasonable use-case and it is a very small change to QEMU,
which introduces hardly any complexity or maintenance burden.

> > There isn't zero utility there, but I don't really think
> > there's enough to justify cluttering up QEMU with when
> > "-cpu cortex-a15" is not very much more to type, and
> > has the advantage of being something that actually
> > exists in reality.

As mentioned above, there is utility and saying that it is "clutter" is a
bit of an exaggeration (it is 5 deletions(-) that introduces *one* new
option).

> 
> There is a clean definition of an ARM CPU without any IO however which
> has utility in compiler testing.

I agree.

-- Meador